# Sangam Protocol

Sangam is a protocol that seeks to implement the properties described in this [doc](https://hackmd.io/yiQXUShIS6OlZcfylpphFQ) in order to create free and open internet platforms. Sangam is essentially an extension of ActivityPub that enforces certain properties between users and servers [CA: wording is kinda vague here]() while also creating a blockchain [CA: idk if we wanna create a blockchain?]() that can serve as a governance and identity service for multiple Sangam communities.

For a description of the ActivityPub protocol: see [here](https://www.w3.org/TR/activitypub/).

### Key Additions:

#### 1. Public/PrivateKey authentication

ActivityPub does not specify a specific authentication scheme, however most ActivityPub communities use OAuth2.0 or something similar which involves a traditional username/password scheme. Since we are building platforms that must be "transferrable" from one operator to another, we cannot rely on username/password schemes or any scheme that gives operators privileged information on a user's authentication info. Thus, users must authenticate by proving ownership of a secret privatekey that corresponds the the public key that the operator knows is associated with the user. In the case of operator replacement, the new operator can simply be provided the publickey without any security issues.

##### 2. Decentralized Identifiers

Sangam will use decentralized identifiers, spec [here](https://www.w3.org/TR/did-core/) to identify both users and platforms. These DIDs must be registered on a blockchain that the platform can query identities from. Users will have a DID so they can self-attest to their identity on the blockchain and then use that DID in any Sangam community they wish. They can also retain this identity even as they move across platforms.

Meanwhile platforms will also have DIDs that identify them to their users. This DID will also be registered on the blockchain but critically will be controlled by the governance mechanism of that community. The DID will resolve to the current operator of the platform. If the community wishes to replace the operator, they simply use the governance mechanism to update the value that the DID resolves to, at which point all users accessing the platform will atomically switch to the new operator's server.

##### 3. Blockchain Governance

Building on the previous point, there must be a decentralized governance mechanism for users to make decisions about the community without undue influence from operators. To accomplish this, a Sangam community will run its governance mechanism on a blockchain (ideally one that serves many Sangam communities) so that it is uninfluenced by the operator. When a Sangam community registers itself on a blockchain, it must instantiate a specific governance algorithm (chosen from a set of gov algorithms the blockchain supports), an initial distribution of community-specific governance tokens, and a set of entities that can mint and burn governance tokens for new or removed users respectively.

Any user with governance token(s) can then participate in any proposal pertaining to that community by submitting governance transactions to the governing blockchain. These proposals may range from votes on content/privacy policy updates, moderation team elections, or even operator replacement. [CA: the blockchain needs to be DID compatible, ie the gov algos need to be able to update DID Documents.]()

##### 4. Moderation RPC

As hinted above, the moderators and operators of a community need not be the same entity; and they can both be independently elected by the community. Thus, operators must expose a suite of moderation RPC methods that moderators can use to remove or moderate content on the platforms as well as eject or accept members into the platform.

##### 5. Client-side content (optional-per-client)

With the introduction of DIDs, users own their accounts; however most ActivityPub communities host all content on a centralized server. This becomes an issue in the event of operator-replacement. Changing the DID will allow all new content to appear on the new operator's server; however there is no guarantee that old content will be ported over.

To mitigate this, clients may *optionally* choose to mirror their outbox (their list of outgoing messages) elsewhere (either in local storage or IPFS or whatever). In the event of operator replacement, clients can provide their old outbox to the new operator who can redeliver the messages to all their respective inboxes and thus _partially_ reconstruct the old state of the network. [CA: does it actually need to redeliver? Porting old state should be to handle queries right? The content should have already been delivered]()

Note, any client that opts out of this feature may have their old posts lost in the case of an operator replacement. [CA: feature not a bug ++ lol]()

##### 6. Server signatures (optional-per-server)

A sangam community may want to enable the use of "full nodes" that can operate the network along with the centralized operator by keeping track of the state of the network and serving requests from clients. This eases the load on the centralized operator and makes operator-replacement less costly. However, doing this carelessly will result in complete censorship resistance and the inability to enforce any governance-passed policy. The network would cease to be a "community" in any sense of the word.

Building a completely decentralized, censorship-resistant, anonymous content network **IS NOT** the goal of Sangam, nor would it be a desirable or socially good product. Sangam intends to build permissioned, incentive-aligned platforms where users have a say in the platform policies. [CA: well put, new paragraph?]() To that end, all content and users still flow through a centralized (but impeachable) operator. All users sign over their outgoing message before sending it to the server, but the server will then sign over the message as well before delivering it to any inbox. These messages can then be routed through any number of full nodes before reaching the recipient who can verify that the message was approved by the central server. This allows the central operator to do basic checks such as ensuring the sender is a valid member of the platform and the content passes basic checks.

However, after-the-fact moderation remains an issue. The moderation team may sign over the hash of any content/user removed for violation of content policy. This hash table can be periodically polled by clients to cheaply check that any incoming content has not been removed by moderators. [CA: I think we could also allow the operator to send out signed delete messages. Servers receiving should verify the current operator signed this message and then delete the post. In fact I think it is important to state this. I remember reading some european law where protocols must allow for posts to be deleted https://github.com/tootsuite/mastodon/issues/7280]()

[CA: we should have a section discussing caching. with operator incentivized instances, the operator will likely want to pay caching services to better faciliate the service of the instance in distribution locally and abroad. The operator optionally may also run the caching itself.]()

TODO: Full nodes don't need to co-host network and serve requests

[CA: this should all be fully ActivityPub compatible? would be worth while to state this]()

### Limitations

##### 1. No private posts

Since any content posted to a Sangam community must contend with the possibility of byzantine operator behaviour, the Sangam protocol cannot make any guarantees regarding private posts that are only readable to a subset of users. Thus, Sangam will only support Public posts and direct messages. Public posts will be sent in plaintext and signed by the sender, while direct messages to users can be end-to-end encrypted given that all users have a Public/Private key as mentioned above (though a different pair would be used for DMs). This ensures that operators have no ability to attack the confidentiality or integrity of user-sent messages. They can only refuse to relay the messages, though this is grounds for individual exit or in extreme cases collective exit.