Composability is an important and interesting part of the autonomous world, and over the past month I have been exploring how to implement composability with low complexity, efficiency, and rationality. In the process, I discovered the application of composability in social networks.

A homogeneous world means that two onchain games use the same architecture and engine, have interface consistency, and the theme of the game has the same universe. The heterogeneous world is the opposite.

When combining homogeneous worlds, I find that we need to provide developers with enough data sources so that the combinations are meaningful and more interesting. It's like if you only provide reading and writing of coordinate data for a game character, then external developers can only move it, but if you open up data such as HP, ATK and DEF, it will bring more composability. Therefore, the richness of data on the chain can be used as an influencing factor of composability. However, the data that the game itself can provide is always limited, so how can I obtain enough data on the chain?

I think it's onchain social network. When you merge your life data with your game data, it's like entering an autonomous world with your memories.

We are active on multiple social applications every day. It is like an organ for us. It not only serves as a communication tool, it also records our mood, our lives, and our social relationships. The data in social networks is infinitely generated. However, our commonly used web2 social applications are highly centralized. User data is stored in the database, and the user's social behavior is performed by the server. You can only operate through limited data and APIs.

Web2 social applications are like an old-school order book trading system. Trades can only be executed when certain pending order conditions are met.

Onchain social applications are like decentralized swaps. Data owners can freely exchange data, and can customize some special functions to give full play to their combination capabilities.

The onchain social network is the same as the fully onchain game. The social logic between users is implemented using smart contracts. Users’ non-sensitive data can be read directly from the chain, including basic personal profiles (gender, age, hobbies), relationships (friends, family, organizations), interactions (likes, comments, messages). Any onchain game can use this open social data source, and you can even use it to build an onchain Sims game that will synchronize your real-life friendships and social influence.

For more onchain social, I recommend you read The Future of Social is Onchain .

It is not a specific application, it is an infrastructure that serves onchain social applications. Its final form is more like a hyperstructure (the hyperstructure was proposed by Jacob).

Its first principle is onchain, and it also needs to have the following characteristics:

The contracts of the composable social network are deployed on various decentralized networks, adopt an open architecture and are completely open source. Developers do not need to apply for any API key or access permissions, and can freely use their imagination to expand in any dimension. This is like Facebook and Twitter directly opening up the highest permissions to their servers and databases to you.

Users in social networks also have absolute autonomy to decide the functions and display formats of your social applications. No one can unilaterally control your account and data. The development of the network will also be determined by users, core infrastructure contributors, and developers of community components.

Components are a concrete representation of composability, and each component represents a service or function. Every social software has some core functions. In fact, we only use these 20% core functions 80% of the time. Composable social networks componentize these core functions, and users can combine different social functions and services to achieve a more personalized social experience. Our goal is not to build a completely decentralized Twitter. We can use multiple components to combine into an onchain Twitter.

The interoperable interface standard is to facilitate all parties to read and write onchain social component data, just like HTTP, any client and server can send POST, GET, PUT, and DELETE to implement CRUD on resources on other servers. Similar standards can also be used to package functions in smart contracts. When the client makes a request to the contract, it indicates the type and method of operation to be taken, and the corresponding method in the contract returns a response. And the two contracts can also interoperate according to standards.

Ame is a composable social network I'm building, it's still in the experimental stage.

It consists of two core parts:

Ame World

Ame World is a component management contract deployed on each chain. Users can manage their own components by interacting with Ame World.

Ame Component

A component is a container of functionality and data. Component developers can customize get, post, and put to provide users with request methods for operating data.

It looks simple right now, I'm building some onchain stack to serve it, if you're interested, you can visit GitHub for more code and technical details, you can also contact me on twitter.

In the future of composable social networks, we may not be able to kill centralized social applications, but we can build more social tools to reduce the influence of super corporations on us. Prioritize the adoption of more onchain services and infrastructure, using cryptography technologies such as ZK to increase privacy and verifiability. Defining a new specification for open social networks.

Composability is an important and interesting part of the autonomous world, and over the past month I have been exploring how to implement composability with low complexity, efficiency, and rationality. In the process, I discovered the application of composability in social networks.

A homogeneous world means that two onchain games use the same architecture and engine, have interface consistency, and the theme of the game has the same universe. The heterogeneous world is the opposite.

When combining homogeneous worlds, I find that we need to provide developers with enough data sources so that the combinations are meaningful and more interesting. It's like if you only provide reading and writing of coordinate data for a game character, then external developers can only move it, but if you open up data such as HP, ATK and DEF, it will bring more composability. Therefore, the richness of data on the chain can be used as an influencing factor of composability. However, the data that the game itself can provide is always limited, so how can I obtain enough data on the chain?

I think it's onchain social network. When you merge your life data with your game data, it's like entering an autonomous world with your memories.

We are active on multiple social applications every day. It is like an organ for us. It not only serves as a communication tool, it also records our mood, our lives, and our social relationships. The data in social networks is infinitely generated. However, our commonly used web2 social applications are highly centralized. User data is stored in the database, and the user's social behavior is performed by the server. You can only operate through limited data and APIs.

Web2 social applications are like an old-school order book trading system. Trades can only be executed when certain pending order conditions are met.

Onchain social applications are like decentralized swaps. Data owners can freely exchange data, and can customize some special functions to give full play to their combination capabilities.

The onchain social network is the same as the fully onchain game. The social logic between users is implemented using smart contracts. Users’ non-sensitive data can be read directly from the chain, including basic personal profiles (gender, age, hobbies), relationships (friends, family, organizations), interactions (likes, comments, messages). Any onchain game can use this open social data source, and you can even use it to build an onchain Sims game that will synchronize your real-life friendships and social influence.

For more onchain social, I recommend you read The Future of Social is Onchain .

It is not a specific application, it is an infrastructure that serves onchain social applications. Its final form is more like a hyperstructure (the hyperstructure was proposed by Jacob).

Its first principle is onchain, and it also needs to have the following characteristics:

The contracts of the composable social network are deployed on various decentralized networks, adopt an open architecture and are completely open source. Developers do not need to apply for any API key or access permissions, and can freely use their imagination to expand in any dimension. This is like Facebook and Twitter directly opening up the highest permissions to their servers and databases to you.

Users in social networks also have absolute autonomy to decide the functions and display formats of your social applications. No one can unilaterally control your account and data. The development of the network will also be determined by users, core infrastructure contributors, and developers of community components.

Components are a concrete representation of composability, and each component represents a service or function. Every social software has some core functions. In fact, we only use these 20% core functions 80% of the time. Composable social networks componentize these core functions, and users can combine different social functions and services to achieve a more personalized social experience. Our goal is not to build a completely decentralized Twitter. We can use multiple components to combine into an onchain Twitter.

The interoperable interface standard is to facilitate all parties to read and write onchain social component data, just like HTTP, any client and server can send POST, GET, PUT, and DELETE to implement CRUD on resources on other servers. Similar standards can also be used to package functions in smart contracts. When the client makes a request to the contract, it indicates the type and method of operation to be taken, and the corresponding method in the contract returns a response. And the two contracts can also interoperate according to standards.

Ame is a composable social network I'm building, it's still in the experimental stage.

It consists of two core parts:

Ame World

Ame World is a component management contract deployed on each chain. Users can manage their own components by interacting with Ame World.

Ame Component

A component is a container of functionality and data. Component developers can customize get, post, and put to provide users with request methods for operating data.

It looks simple right now, I'm building some onchain stack to serve it, if you're interested, you can visit GitHub for more code and technical details, you can also contact me on twitter.

In the future of composable social networks, we may not be able to kill centralized social applications, but we can build more social tools to reduce the influence of super corporations on us. Prioritize the adoption of more onchain services and infrastructure, using cryptography technologies such as ZK to increase privacy and verifiability. Defining a new specification for open social networks.