AdityaSripal / sangam

Apache License 2.0
6 stars 0 forks source link

Design Discussion #21

Closed colin-axner closed 3 years ago

colin-axner commented 4 years ago

Summary

@AdityaSripal and I have decided to revisit the initial design of sangam and focus in on the exact problems we would like to solve and the solution that would fit it best. We would like to devise something that is robust, usable, and beneficial to humanity.

This likely means we will be in the "design" phase for quite some time and a lot of this fruitful discussion will occur offline and with many different participants, some of whom are not on github. I will do my best to document a lot of that discussion, consideration, and decisions in this issue. Once more concrete ideas are constructed we will update the README and architecture documents. The purpose of this documentation is aimed to be beneficial to our future selves in remembering why we came to these conclusions as well as to be support material for any other groups working and thinking about the same issue and various solutions.

If you would like to participate, please comment on this issue and we will open up the appropriate communication channels.

I will periodically update this initial post on this issue with concrete decisions.

Problem

I will update this when we narrow in on the exact problems

Current Proposal

fora networks

Food for thought

colin-axner commented 4 years ago

Some initial notes I took on rereading the README.

as written in the README, authorship is the original creator of a binary. Proof of this is non-trivial and opens the protocol up to practical attacks that in theory can be mitigated but lead to serious implementation concerns on whether the theory will prove to be true. Slight modifications of binaries, plagiarism being registered, having to de-register bad content. These are very costly concerns even if you have good ml algo's as tools to fight them.

another approach is to simply define authorship as message passing i.e. the author is of the message not the content. This is much easier to prove and might have censorship issues (?) But I believe these attacks are much less effective than the above attacks. If someone removes my ipfs Sig and stores the file, the file is still on my ipfs node with my Sig.

Reasoning: digital social trust turns out to be extremely valuable. Even without being verified on Twitter, an account can be trivially trusted if it is followed by accounts you trust. An account with 10 followers claiming to have made the latest kendrick lamar album will be trivially disregarded as spam. This root of trust bypasses authorship issues.

The main issue I'm concerned with as a user is, I want to subscribe to X creations from creator Y. If creator Y is a good creator it will be assumed they have a non-trivial set of verifiable followers (using this term loosely, verification can be done in many ways). I only care about X messages creator Y signed. Anyone impersonating creator Y is unlikely to have a non-trivial set of verifiable followers.

Reputation lends a hand here as well. If creator Y chooses to plagiarize creator Z, once revealed their social reputation will be diminished and they will likely lose verifiable followers.

It's hard to make a DNS lookup that doesn't double store the same content under different creators leading to non-trivial commit-reveal schemes. But the question is if this is even necessary? Sangam doesn't need to act as a copyright station, rather an aid in distributing and incentivizing good content sharing practices. Also, in the world of many blockchains it seems like a pain to have to register on every single one. Maybe there is a use case for registering your internet identifier if you are a mega-popular creator, but for every day small town creators, I think this is much less of concern as impersonation attacks are unlikely to succeed nor be profitable.

colin-axner commented 4 years ago

Some general questions to ponder:

colin-axner commented 4 years ago

My initial thoughts in responding to the workflow of distribution and responding to the community of consumers.

I create a mostly guitar based song, I have this flac file stored on my IPFS node (furthermore my IPFS node has an allowed list of public keys that can upload content to it). I open up my favorite open source UI portal that speaks ActivityPub (or whatever decentralized content sharing protocol is defacto) and I upload my song in a post to the platform where I host my guitar-based songs. All my public accounts are linked to my root DID (decentralized identifier) which has verified each of my accounts and provides a list of donation addresses and donation models I support (I'm calling this system smart donations for the time being).

Using the smart donation system I link my donation model which happens to be 50% to my currency (fiat or crypto) account and 50% to a random selection of 5 pre-selected charities. All the charities only take traditional fiat (maybe only usd or euro) so any incoming payments are automatically routed as IBC packets to a zone which exchanges the donated cryptocurrency to fiat and pays the resulting USD or Euro to the charities accounts and sends back a receipt in the acknowledgement.

Upon posting my content, the post is sent out to all my followers of my guitar based songs (the tag I attached to the content). Within the post is a link to the IPFS file that can be downloaded freely or replicated on another IPFS node. This marks the end of the "distribution" workflow as producer.

This all seems great, but now becomes the question of how to tap into the incentive mechanism that is community involvement. Protocol wise, I probably had to post my content on platform X, in community Y that is specifically setup for guitar based songs. All members of community Y can trivially interact with this post, now the question becomes, how can I allow a follower on platform Z to interact with this post, assuming they do not have an account on platform X. Maybe this is already trivial if they speak to the defactor content sharing protocol. What account would the centralized UI determine to respond to this post? I guess the user could pre-set this, ie I'd like to follow/interact creator X and content Y using my account A. This area I'm still a bit fuzzy. I think it makes a lot of sense to contain content based on communities, but still allow easy interaction from other communities.

In general, considering all this. I have a couple main concerns regarding the root protocol.

ActivityPub seems to be very well suited for all this. I think we will need to look closely at the protocol and see if it is limited in any regard

colin-axner commented 4 years ago

The following is a summary of a discussion I had with @shrav-k and Colin Acton. It is based on my notes so some ideas I may have misinterpreted.

The discussion centered around the questions I asked at the beginning:

We quickly began discussing the interaction between physical proximity and digital connection. In the current day, there is an ever growing disconnection to local communities. This disconnection is extremely different from past times when local communities were very social (due to lack of digital connection). Those who wanted to share ideas or distribute content were forced to do so physically which can introduce a multitude of social pressures and social incentive.

It was also noted that in current times, most fruitful interaction with the internet is with individuals known in real life via discord, zoom, google meet, etc. Also, a balance of notification priority lends a hand here. Being able to draw lines on when you want to be notified based on what social group you are interacting with. For example, getting notifications when you are online in the chat vs never receiving any notification if you are offline when the message is posted.

We also discussed the importance of balancing operator power as described in the economy of platforms blog post linked above. Currently the structure of mastodon does a complete flip from centralized social networks. Centralized social networks give 100% of platform power to operators which results in abuse of producers and consumers. Mastodon essentially offers very little to zero incentive for one to be an operator. The only incentives I can think of at the moment are 1) not being censored and 2) seeing your community flourish. In terms of capital, it is strictly a loss for operators and can be time consuming as well. For a lot of use cases I could see many individuals falling back to using Signal for community social interaction.

When introducing operator incentive mechanisms we discussed the importance of the community hijacking control. IMO this would be in the form of allowing any consumer to rull a full node of the instance. While this does not allow for the community to control the server hosting, it does at least allow all archives to be maintained in the event of a mass migration.

Lastly we began discussing the issue of echo chambers. Through usability, mastodon allows for echo chambers to occur very easily. By joining an instance, I can trivially be served all the content of my community. Obviously it is encouraged that users maintain cross community interaction, but is quite difficult to find valuable people to follow right now. One needs to devote quite a lot of time to sorting/searching through different instances for interesting accounts to follow. Therefore, echo chambers are a very important consideration in terms of mitigation to the best of our ability.

Some general takeaways for echo chambers:

After this we slid into discussion around potential applications for ActivityPub based platforms with regards to activism and organization of people such as for unions. This was tied back to physical locality of social networks. So main points that were punched in here for unions specifically:

we felt like initial decentralized communities would flourish when centered around real world initiatives where incentive is aligned at all levels and existing centralized solutions fail to support the cause.


Design Ideas

This very fruitful discussion lead me to some possible design ideas. Both require support for decentralized identifiers (natively by ActivityPub preferably :pray: ) .

Locally based invitations to communities

As we discussed, it can be very difficult and intimidating to join a new community in the real world or even just get to know all your neighbors. The question arises, how can be support this interaction via decentralized communities on the internet? We can't rely on IP addresses because spoofing is trivial. One solution is to rely on locally distributed decentralized identifiers. Current centralized applications do a modified version of this where they typically rely on phone numbers for identifiers (lets stop doing this!). Phone numbers are usually locally distributed. If I have a spanish phone number, I probably live in Spain.

So how do we do this with DID's? One way (not necessarily optimal) is to allow communities to be certificate authorities. Let's say the local art collective in Chicago decided to create an online network of their members who live in chicago to allow for in person and online interaction, but limit the scope of their moderation. We can say here invite is based on locality. To enforce this, Sara who is a resident of Chicago would submit a request to join providing their home address based in chicago and their identifier. The art collective would send a letter in the mail with some randomized string. Sara would then create proof of receiving this string by signing of it with the public key that is identified by their decentralized identifier. The art collective upon verifying the proof could then allow Sara in as a member to the online and physical events. This interaction could probably be abstracted in a QR code scan by an admin of the org.

Currently, a large number of groups I'd like to join only support facebook groups for interaction. Facebook makes it virtually impossible to interact even with a "public" group as a non-member. By using ActivityPub to power this interaction, the user doesn't even need to be on the sample platform as the organization to interact. This is just preferred to get better UI experience.

The art collective could still maintain forums for broader world wide digital interaction, but this is a way that communities could feel safe and create a ramp for onboarding real world interaction. Digitial interaction is inherently limited and should be used as a tool rather than a substitute.

I can imagine this sort of scheme could be applied in different ways to connect up communities. We can also use referrals to bypass invitation schemes if desired. This could be applied to unionization where, in the example of uber, where the person joining needs to prove they are a driver and don't work for uber as registered employees.

You might even be able to rely on socially "trusted" certificate authorities. If there exists a network of organizations that trust each other, only one needs to provide the proof of location service.

This design is not secure, but I imagine in many cases it does not need to be. It just needs to raise the barrier enough to make entry non-trivial.

Operator sets

Control of operator power is hard. Incentivizing operators is also hard. One scheme (with flaws) that I can think of uses a blockchain and a decentralized identifier on that blockchain to identify the server name of a community.

Lets say we have a very popular community on mastodon. Everyone and anyone wants to be on this instance because influential accounts exist here and there are good add ons, plug ins, and operation. Lets say this community is so nice they create a fund to distribute to a set of operators maintaining the chain. This could occur via a blockchain, but does not need to. A blockchain contract has been connected to the community via an decentralized identifier. This identifier resolves to the latest server name. Any user on this instance using verification scheme X (maybe a user account requires X amount of "verified" followers) can prove their existence and get a vote with a unit of 1 voting power. This vote corresponds to control over the decentralized identifier (which perhaps also controls the community fund).

Lets say an operator or multiple start acting maliciously. Assuming the community supports full nodes, the community could vote on a proposal to do a mass migration to new server name controlled by operator set Y. If this proposal passed on the blockchain, the decentralized documents on the blockchain would update to point to the new server name causing any resolution of this identifier to go there. This very neat feature allows for the mastodon community to migrate to a new server URL and assert power over the malicious operator set!

some general requirements:

In this scheme, consumers and producer maintain ultimate authority over operators. Parameters could be modified, maybe you get more voting power based on how large of a producer you are. Incentive mechanisms (including capital) can be created without allowing for runaway operator set power.


Some questions I want to consistently be asking

Some random ideas briefly discussed:

colin-axner commented 4 years ago

After some discussion with @AdityaSripal we came to consensus on the following conclusions

capital incentives via payments

Payment integration to producers/operators is likely to occur naturally and right now there exists very little friction to paying someone (bandcamp, venmo, open collective, crypto etc). While smarter donation/monetization mechanisms, streaming payments automatically and less fractured payment interaction would be nice, we don't need to give it much attention or effort. Existing projects will likely build all this within the next few years. Easier to wait for a plugin or standards to be settled upon.

Forkability

The primary question in the stability of self-governing decentralized social networks is can it be forked? This is an open problem and open question specifically for ActivityPub (we aren't sure whether this is currently supported). Can anyone run a full node? This is extremely valuable in giving the community power to recover it in the instance of a malicious or abusive operator. Forking would be an act of protest and would allow for operator incentives to be checked by the community forking the operator out. Robust self-governing systems doesn't make too much sense for small communities when everyone knows each other, but in medium to large communities where a user may not be able to trust another user, social consensus and power need to be able to be exercised.

Operator Incentives

Operators are going to need incentives, otherwise we will likely converge very large instances. Moderation falls under the hat of the operator and this job is essential in maintaining community quality. Compensating operators via incentives for this work will likely lead to higher quality communities.

Forkability and operator incentives are our primary interests at the moment.

colin-axner commented 3 years ago

In case anyone has been following this issue, this discussion resulted in material protocol specs which can be viewed on fora networks github (the rebranded Sangam)