Merge branch 'master' into 'ssb'

# Conflicts:
#   design/preexisting/protocols/template.md
This commit is contained in:
Jay Graber 2020-06-05 16:42:44 +00:00
commit 095e8b557f
7 changed files with 270 additions and 14 deletions

View File

@ -0,0 +1,69 @@
# Aether
Aether is a Reddit-like p2p social network - a public discussion forum designed with ephemerality and mutability in mind. It is available as a desktop application. Aether's p2p protocol is called Mim. In practice, Aether is the only application using Mim, but it could support other applications.
### Identity
Identities in Aether are based on keypairs, like in ssb. As with ssb, the human-readable usernames are not unique, although users can choose a custom nickname. Multi-device usage is currently possible, but difficult (requires manually porting a user config file). There is a strategy for multiple device logins under development that would allow users to store and sync encrypted keys from a remote backend.
### Networking/Message passing
Aether is a flood network where every node stores everything. All nodes download content as well as provide it to other nodes. Communities with objectionable content can optionally be blocked by the user, so that content is not stored on their machine.
Aether comes with a list of bootstrap nodes. Nodes find each other through a probabilistic search over a network table. This is a random process in which no patterns of data distribution can be discerned, so only the last hop of where data came from is visible, not the source. Once nodes are connected, they sync their data.
Syncing nodes request caches of data from others. Every node stores pre-packaged answers to common queries. Data from each endpoint (boards, threads, posts), will be cached every day, and stored for 7 days, after which it is no longer cached. Bootstrapping nodes do not download the entire history of the network - only the last 7 days by default.
New posts have a 0 to 10 minute delay, as it takes time to traverse the p2p network.
### Data Storage/Message Persistence
Aether's data structure is a DAG (directed acyclic graph). It allows insertion and updates of content. Deletion of content is achieved by inserting a blanck update. The backend keeps a local SQLite database up-to-date with the state of the network. The frontend compiles and presents the graph data.
Posts are ephemeral. After a certain period of inactivity on a post (the default is 6 months from the last reference), it automatically gets deleted by nodes on the network. If a post continues to referenced, it stays up, so actively discussed topics do not disappear.
### Moderation/Reputation
Each sub-community has its own moderators, which communities elect or impeach themselves. Like sub-reddits, communities largely govern themselves. Mods (moderators) can approve or delete posts.
Users can report posts. Reports go to mods of the community. Users elect moderators in communities, and can impeach them. If a user votes to impeach a mod, the mod's actions will be ineffective for that user, even if the vote wasn't won. All mod decisions are public history.
Moderator elections begin once a community has more than 100 active users within the last 2 weeks. Voting thresholds for moderators is a 51% positive vote of at least 5% of the community's members. To prevent hostile takeovers, the population of communities is determined on a 2-week trailing basis, and mods can temporarily lock a community to new entrants.
Users who wish to be mods can enable 'mod mode', which allows them to proactively attempt to approve or delete posts. Their moderation history can be observed by others considering electing them as an official mod.
Whitelists and blacklists are used to moderate the collection of communities. When users join, the default is to only display SFW communities on a vetted whitelist, to ensure the safety and comfort of a user's initial experience.
### Spam
Aether combats spam by requiring users to complete a small "proof-of-work", a brief hashing function, before they post. This rate-limits the amount of posts that a user can send out to the network, making it more expensive to flood it with spam.
### Social/Discovery
Users can search communities, content, and people. The user interface has tabs to discover newest content and popular content.
There is no follow functionality for other users at present.
### Privacy/Access Control
All posts are public.
### Monetization
The Aether p2p version is supported through Aether Pro, a SaaS version of Aether designed for private work deployments.
### Interoperability
Aether p2p is working on implementing a chat that bridges to Matrix p2p.
### User Experience & Scalability
Aether is currently only available on desktop. There is no mobile app, as mobile devices have limited disk space and energy stores to run the p2p network.
However, a mobile app is under development that uses the following method: Running an Aether host in a docker image on a home server, and allowing mobile devices to connect to it.
Creating a mobile app in a way that requires users to run home servers, rather than simply providing full nodes that would allow a mobile app to download content, is a design decision that maximizes decentralization at the expense of user convenience. Every mobile user running a home server will also still be providing capacity to the network to help it scale in a purely p2p manner.
### Links
[Mims protocol](https://getaether.net/mim-docs/)

View File

@ -0,0 +1,66 @@
# Diaspora
Diaspora was a federated social network released in 2010. It is still in existence, although not widely used. It does not use the ActivityPub federation protocol. In the diaspora protocol, messages are passed between servers.
The federated nodes, called "pods", are hosted by different individuals and institutions. User accounts, which are tied to pods, are called "seeds".
### Identity
Users joining Diaspora pick a pod to register their identity with. User identities contain the username, the hostname, and the port if their server does not listen on the default ports.
`alice:example.org`
It is not possible to move a user account to another pod once created.
### Networking/Message passing
Diaspora uses the Webfinger protocol to discover users from other pods. User information is returned via hCard, an open microformat standard for identity.
Messages sent between servers are serialized to XML, then signed using the Salmon Magic Signature protocol.
### Data Storage/Message Persistence
User data in Diaspora is tied to their pod server. A user can export all of their data at any time, to reduce the risk of their pod going down.
### Moderation/Reputation
Like Mastodon, moderation is done at the server level. When ISIS joined the Diaspora network in 2014 after they were censored by Twitter, all the larger pods moved to block their server.
In this [Github issue about admin reports](https://github.com/diaspora/diaspora/issues/7316), it is possible to see how communities struggle when tools for moderation are not built into federated networks from the start. This user requested a way to forward spam reports to the source pod, as that was the only way to remove content from the entire network. Without this feature, pod administrators resorted to manually searching for and contacting other administrators.
### Social/Discovery
Like Twitter, Diaspora includes hashtags and mentions.
### Privacy and Access Control
Profiles in Diaspora can be public or private.
Private messages in Diaspora are encrypted.
Diaspora allows users to group their contacts into "aspects". Limited posts will only be shown to contacts in the selected aspect.
Communication between pods is encrypted, but data stored on pods is not. Administrators could access all profile and post data.
### Monetization
Diaspora was initially funded through a kickstarter that raised $200,000.
### Interoperability
Friendica instances are a part of the diaspora network, and natively support the Diaspora protocol.
Diaspora posts can be propagated to accounts on [WordPress, Twitter, and Tumblr](https://wiki.diasporafoundation.org/Integrating_other_social_networks).
Diaspora has not integrated with ActivityPub, despite the similarities of approaches to federated social. Discussion of this topic can be found on the [Discourse forum](https://discourse.diasporafoundation.org/t/lets-talk-about-activitypub/741).
### Metrics
[Number of Diaspora users](https://fediverse.party/en/diaspora)
### Links
[Diaspora Federation Protocol](https://diaspora.github.io/diaspora_federation/)
[Webfinger](https://tools.ietf.org/html/rfc7033)
[Salmon Magic Signatures](https://cdn.rawgit.com/salmon-protocol/salmon-protocol/master/draft-panzer-magicsig-01.html)
[Discourse Forum](https://discourse.diasporafoundation.org/)

View File

@ -0,0 +1,49 @@
# Steemit
The Steem cryptocurrency was created for content monetization in social sites. Steemit, a Reddit/Medium-style social network, was the first site built to use Steem. Later, several other platforms including Dtube, a decentralized Youtube, also used Steem for monetization.
User identities and post data are stored on the Steem blockchain.
### Identity
User identities are stored on the Steem blockchain. New account creation requires an email and phone number, and must go through a review process
A Steemit account functions as a cryptocurrency wallet, and users are responsible for their own key management. There is no account recovery available, and funds can be lost or stolen if the key is compromised. Accounts cannot be deactivated or deleted, since they are permanently stored on the Steem blockchain.
### Networking/Message passing
### Data Storage/Message Persistence
Post data is stored on the Steem blockchain.
### Moderation/Reputation
Reputation determines the weight of votes in the network. Older accounts have more reputation.
### Spam
Since there is a monetary incentive to create fake accounts to upvote posts, a centralized spam prevention method was necessary to combat abuse. The new account creation process which requires review of an email and phone number is the method used by Steemit.
### Social/Discovery
### Privacy and Access Control
### Monetization
Steemit mined 80% of Steem in the first week. Steemit benefited from the appreciation of Steem during the 2017 cryptocurrency run-up, but did not manage the bear market well and had to lay off much of its staff. When a companys monetization strategy depends on a volatile asset, its leaders have to be prudent portfolio managers as well as good operators.
Other than depending on Steem price appreciation, Steemit monetizes through users promoting their posts. When users perform certain actions on Steemit, they earn Steem. Creating posts that get upvoted qualifies users to earn from a rewards pool. Upvoting posts that later become popular can earn voters a curation reward. Votes are weighted by reputation, which accumulates with age, so older accounts of early adopters have more power in the network. This, as well as the fact that Steem tokens could be mined easily early on, means that Steemits incentives are geared towards early adopters.
### User experience (if applies)
### Interoperability
what is the minimum requirement for a message to enter or leave the system?
### Scalability
### Metrics
There are over a million users on Steemit.
### Links

View File

@ -0,0 +1,55 @@
# Zeronet
Zeronet is a browser for a decentralized network built on BitTorrent and Bitcoin. Instead of having IP addresses, Zeronet site addresses are Bitcoin public keys.
Example sites created on Zeronet include ZeroTalk (like Reddit), ZeroBlog (microblogging), ZeroMail (encrypted mail), and ZeroMe (p2p social network).
ZeroMe is a proof-of-concept that demonstrates how to build a Twitter-like site in a decentralized browser. It has not received wide usage.
### Identity
The creator of a site signs the files with the private key, and the public key is the site address. This is a Bitcoin key which can be exported to a wallet, allowing funds to be sent to the address and collected by the site creator. Zeronet domains end in `.bit`.
ZeroId is an authorization provider that lets you interact with sites without contacting the owner, and is used for sites with user interaction like ZeroMe.
### Networking/Message passing
Zeronet uses the BitTorrent network to find peers that are seeding the site to download the site content from. When a user visits a site, they download the site files. Once they've visited, they start serving that site as well, seeding it to others.
### Data Storage/Message Persistence
Zeronet uses BitTorrent trackers and its own variety of trackers (zero://).
### Moderation/Reputation
Blacklists are opt-in.
ZeroId provides some control over user accounts to fight spam, by limiting the number of registrations from an IP address.
### Social/Discovery
There are a few search engines for Zeronet, which have scraped and index the network. Zeronet addresses are commonly shared out-of-band.
### Privacy and Access Control
Sites that take user input, like ZeroMe, ask the user for permission to grant read/write access.
### User Experience
Zeronet's decentralized hosting design allows for one-click site cloning. Popular sites scale with demand, as visitors become seeders of site content as well.
### Interoperability
Despite being compared to Beaker Browser and IPFS, Zeronet does not interoperate with other sites, or even with BitTorrent.
Zeronet can be run over Tor for privacy. but it does not support .onion sites. I2P is not supported.
### Monetization
The Zeronet project relies on tips.
An interesting element of monetization in Zeronet is that the fact that site addresses are bitcoin addresses, which means that site owners can be tipped directly to the address. The owner can retrieve the funds by importing the private key into a bitcoin wallet.
### Links
[Zeronet](zeronet.io)

View File

@ -1,10 +1,8 @@
# Name
### Identity ### Identity
### Networking/Message passing ### Networking/Message passing
### Data Storage/Message Persistance ### Data Storage/Message Persistence
### Moderation/Reputation ### Moderation/Reputation
@ -18,12 +16,10 @@
### Interoperability ### Interoperability
in particular - what is the minimum requirement for a message to enter or leave the system? what is the minimum requirement for a message to enter or leave the system?
### Scalability ### Scalability
### Metrics ### Metrics
### In the wild
### Links ### Links

View File

@ -1,16 +1,37 @@
# Network Structure # Network Structure
Federated approach to decentralized network architectures can be categorized as federation where you pass messages between systems (SMTP, XMPP, ActivityPub), and federation where you replicate data between systems (Git, Matrix, NNTP). ### Federated networks
P2p networks can be analyzed on a spectrum of fully distributed and p2p, to partially distributed. Supernode architectures, and points of logical centralization in p2p systems, should be addressed. Federated approaches to decentralized network architectures can be categorized as federation where you pass messages between systems (SMTP, XMPP, ActivityPub), and federation where you replicate data between systems (Git, Matrix, NNTP).
- i.e. Textile cafes peers as p2p network infrastructure (https://docs.textile.io/concepts/cafes/) #### Passing messages between systems
Hybrid federated/p2p approaches should be considered - i.e. a client-server architecture, where you can optionally run the server client-side. Federated networks that pass messages between systems include SMTP (email), XMPP (chat), and ActivityPub (Mastodon). This is a straightforward approach for systems mainly concerned with one-to-one communications, such as email and chat, because messages do not get replicated across servers that do not concern them.
- i.e. Matrix's new P2P work ActivityPub, a federated social protocol that passes messages between participating servers, is used in one-to-many social applications like Mastodon, a decentralized Twitter alternative. Unlike Twitter, there is [no global shared state across all servers](https://docs.joinmastodon.org/user/network/), so there is no way to browse all public posts. The federated timeline shows public posts that the user's server knows about. The majority of posts surfaced are from people other users of the server follow.
- categorization of blockchain light clients?
[pubsub in the libp2p project](https://docs.libp2p.io/concepts/publish-subscribe/) #### Replicating data between systems
[GossipSub](https://research.protocol.ai/posts/201912-resnetlab-launch/PL-TechRep-gossipsub-v0.1-Dec30.pdf) discussion of gossipsub as a decentralized scalable routing protocol Matrix is a federated protocol that replicates data between systems. Messages in Matrix are replicated over all the servers whose users are participating in a given conversation - similarly to how commits are replicated between Git repositories. The conversation history of the room being replicated across servers allows nodes to resync to the conversation if they go down. To ensure privacy of conversations in rooms, since those conversations are stored across many servers, Matrix has prioritized e2e encryption.
If bluesky adopts a federated architecture, further work should be done to assess how message passing and message replicating systems affect scalability. Certain types of messages, such as popular topics, could be widely replicated to ensure global availability, and others, such as messages between two users, could be shared only with participating servers.
### P2p networks
P2p networks can be analyzed on a spectrum of fully distributed and p2p, to partially distributed. Many p2p systems have supernode architectures, and points of logical centralization.
Ssb is a fully distributed p2p social protocol that avoids [logical centralization and singletons](https://handbook.scuttlebutt.nz/stories/design-challenge-avoid-centralization-and-singletons), as a design experiment and matter of principle. Ssb was designed for social applications, where data can be passed along follow relationships among users. Data is propagated through a gossip protocol among people who follow each other. As part of its commitment to full decentralization, ssb has no DHT, no universal human-readable namespace, and comes with no bootstrap nodes. New users seeking to connect to the network must often use a [pub server](https://github.com/ssbc/ssb-server/wiki/pub-servers), which is a peer that is always online, has a public IP address, and offers invite codes to new users.
In IPFS and Hypercore, the focus is on content and not social relationships, so there are central directories to aid in discoverability of content, and nodes that guarantee persistence of content if the original host is offline. 'Gateways' are essentially supernodes, and DHTs used for discovery of content are points of logical centralization.
Content in IPFS and Hypercore is accessible over HTTP through gateways. These are nodes that run the p2p protocol and allow HTTP requests to access content in the p2p network through it. Some of these gateways, like the one provided by the IPFS developers themselves, are quite large and become points of centralization. However, anyone can [configure a gateway](https://medium.com/@rossbulat/introduction-to-ipfs-set-up-nodes-on-your-network-with-http-gateways-10e21ea689a4) and run one themselves, as the system is permissionless.
DHTs, distributed hash tables, keep track of who has what data in the network. The data itself may be spread out across many different nodes, but the [DHT](https://docs.ipfs.io/concepts/dht/) serves as the central index of where it is.
### Hybrid networks
Hybrid federated/p2p approaches also exist, such as a client-server architecture where you can optionally run the server client-side.
Matrix's new p2p implementation takes a hybrid approach, moving away from a strictly federated model towards p2p functionality. The new p2p matrix client essentially runs the server client-side, allowing it to participate in the existing federated Matrix ecosystem as a p2p node.
Light clients in blockchain architectures could also be considered an example of a hybrid approach to p2p network participation. Full nodes participate fully in the blockchain network, storing the entire history and validating all blocks and transactions as they come in. Light clients do not store the full history of the chain, which can be many GBs, but request the relevant history from a full node. This allows light clients to transact without having to store the entire history themselves.