Edits
This commit is contained in:
Jay Graber
parent
30338f4e39
commit
ce0a2dde64
24
overview.md
24
overview.md
|
|
@ -51,7 +51,7 @@ This section will be structured as comparisons between how protocols handle thes
|
|||
- Business models
|
||||
- Payment
|
||||
|
||||
#### Filtering
|
||||
#### Discovery
|
||||
|
||||
- Queries
|
||||
- Curation
|
||||
|
|
@ -71,13 +71,15 @@ This section will be structured as comparisons between how protocols handle thes
|
|||
## Contributions
|
||||
|
||||
Thanks for contributions from: (alphabetize when done)
|
||||
Burak Nehbit
|
||||
Eugen Rochko
|
||||
Golda Velez
|
||||
Molly MacKinley
|
||||
Matthew Hodgson
|
||||
Mark Nadal
|
||||
Sarven Capadisli
|
||||
Paul Frazee
|
||||
Ian Preston
|
||||
Rahul Kothari
|
||||
|
||||
- Andre Staltz
|
||||
- Burak Nehbit
|
||||
- Eugen Rochko
|
||||
- Golda Velez
|
||||
- Molly MacKinley
|
||||
- Matthew Hodgson
|
||||
- Mark Nadal
|
||||
- Sarven Capadisli
|
||||
- Paul Frazee
|
||||
- Ian Preston
|
||||
- Rahul Kothari
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Account credentials are managed by the user’s instance, so if users forget the
|
|||
|
||||
### Data Storage/Message Persistance
|
||||
|
||||
As a federated system, ActivityPub is not opinionated about how messages are persisted as long as each server follows the protocol requirements. Each server is expected to maintain an inbox and outbox for each of its users.
|
||||
As a federated system, ActivityPub is not opinionated about how messages are persisted as long as each server follows the protocol requirements. Each server is expected to maintain an inbox and outbox for each of its users.
|
||||
|
||||
### Moderation/Reputation
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ Each instance sets its own moderation policies, either through the unilateral de
|
|||
|
||||
Messages are addressed to a user at a specific server, and normal DNS and ip address routing are used to find the server addressed.
|
||||
|
||||
Users can push messages to the special 'public' group which makes them available to all interested users. "Like"s and "Follow"s may be used by servers to determine which public messages to accept/retrieve. For example, the followers of a user who Likes a post may receive the post in their feed.
|
||||
Users can push messages to the special 'public' group which makes them available to all interested users. "Like"s and "Follow"s may be used by servers to determine which public messages to accept/retrieve. For example, the followers of a user who Likes a post may receive the post in their feed.
|
||||
|
||||
Instances may accept delivery of messages addressed as 'public' to a shared inbox on the instance but are not required to.
|
||||
|
||||
|
|
@ -40,22 +40,24 @@ Federated social networks require both hosting and development costs to maintain
|
|||
|
||||
### Interop with other systems
|
||||
|
||||
The spec mentions delivery to third-party apps but unsure how/how much this happens in the wild.
|
||||
The spec mentions delivery to third-party apps but unsure how/how much this happens in the wild.
|
||||
|
||||
Requirements for interop: implement the ActivityPub protocol (are there different requirements for 3rd party receivers?)
|
||||
Requirements for interop: implement the ActivityPub protocol (are there different requirements for 3rd party receivers?)
|
||||
|
||||
### Scalability
|
||||
|
||||
### Metrics
|
||||
|
||||
### In the wild
|
||||
### Implementations & Applications
|
||||
|
||||
[Mastodon](https://mastodon.social/about) (the largest federated network built on ActivityPub) has 2699 nodes and 2.6M users as of 5/2020 (Mastodon home page asserts 4.4M, a bit more than what the-federation.info stats provide; maybe some servers are not counted)
|
||||
List of ActivityPub projects: https://github.com/BasixKOR/awesome-activitypub
|
||||
|
||||
[Pleroma](https://pleroma.social/) is compatible but running different software, also talking the ActivityPub protocol. According to stats at [the-federation.info](the-federation.info), Pleroma has 620 nodes with 35K users as of 5/2020 Users on Mastodon and Pleroma can communicate.
|
||||
[Mastodon](https://mastodon.social/about) (the largest federated network built on ActivityPub) has 2699 nodes and 2.6M users as of 5/2020 (Mastodon home page asserts 4.4M, a bit more than what the-federation.info stats provide; maybe some servers are not counted)
|
||||
|
||||
[Pleroma](https://pleroma.social/) is compatible but running different software, also talking the ActivityPub protocol. According to stats at [the-federation.info](the-federation.info), Pleroma has 620 nodes with 35K users as of 5/2020 Users on Mastodon and Pleroma can communicate.
|
||||
|
||||
Gab is running a fork of the Mastodon software but has been banned; technically users there could communicate with the others if they were not explicitly banned.
|
||||
|
||||
### Links
|
||||
|
||||
[https://www.w3.org/TR/activitypub/](https://www.w3.org/TR/activitypub/)
|
||||
[https://www.w3.org/TR/activitypub/](https://www.w3.org/TR/activitypub/)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
# Data
|
||||
|
||||
Data structures, data availability, persistence, and mutability in decentralized applications.
|
||||
|
||||
Decentralized systems do not have a single central system to coordinate updates.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Filtering
|
||||
# Discovery
|
||||
|
||||
In decentralized networks, whether federated or p2p, there is often no global search functionality.
|
||||
|
||||
|
|
@ -1,30 +1,36 @@
|
|||
# Decentralized Governance
|
||||
# Governance
|
||||
|
||||
May sound like an oxymoron - but in order for the decentralized web to work, decisions have to be made about protocols, moderation, design and many other topics.
|
||||
Decentralized protocols need governance systems that can make decisions about protocol evolution, moderation, design, and other topics. The purpose of this document is to review how existing projects govern themselves. As all the protocols and applications covered are open source, we will look into general open source governance as well.
|
||||
|
||||
The purpose of this doc is to overview how existing projects govern themselves, and how decisions and compromises have been made in the past.
|
||||
### ActivityPub
|
||||
|
||||
### SocialWeb
|
||||
Negotiations between numerous parties ending with the design of ActivityPub. Consensus based?
|
||||
|
||||
### Mastodon
|
||||
Federated system. Each server admin can create their own moderation rules as well as a theme for their server, publish their TOS which may include rules about whether data can leave the server, etc. Users choose which server to join.
|
||||
|
||||
No formal project-wide code of conduct/bylaws, more work talks
|
||||
ActivityPub was developed by the Social Web Working Group (SWWG), which ran 2014-2018, and culminated in the recommendation of a set of social protocols including ActivityPub. It has reached W3C recommendation status, and is currently stewarded by the W3C.
|
||||
|
||||
### Matrix
|
||||
Uses a vote of confidence in a nonprofit foundation to periodically review the leaders. In the interim functions similar to a standard nonprofit with leadership making decisions?
|
||||
|
||||
Servers in Matrix also have terms of use that users agree to when they join. Rooms may have moderators who can remove people from individual rooms.
|
||||
Matrix was [initially developed within Amdocs](<https://en.wikipedia.org/wiki/Matrix_(protocol)>) by developers building a chat tool. Amdocs funded development from 2014-2017. In 2017, the core developers started a company, [New Vector](https://vector.im/), which now drives development. The Matrix protocol and specification is stewarded by the [Matrix.org Foundation](https://matrix.org/media/2019-06-10%20-%20Matrix.org%20Foundation%20CIC%20Rules.pdf). There is an annual vote of confidence in the project lead.
|
||||
|
||||
### Links and more examples
|
||||
(some are from the discussions at Mastodon on whether to have a formal structure)
|
||||
### IPFS
|
||||
|
||||
[How the Node.js Foundation Utilizes Participatory Governance to Build Its Community] (https://thenewstack.io/node-js-foundation-utilizing-participatory-governance-models/) - more about opening commit rights to the repo earlier and more quickly?
|
||||
IPFS was built by the company [Protocol Labs](https://protocol.ai/), and continues to be stewarded by it in conjunction with an open source community.
|
||||
|
||||
## Blockchain governance
|
||||
|
||||
Most blockchains are governed by companies and foundations that direct resources towards development. Only a few projects have on-chain governance, in which funding and decision-making is actually executed on a blockchain network itself.
|
||||
|
||||
On-chain Governance: Dash and Decred
|
||||
|
||||
[Decentralized Network Governance: Blockchain Technology and the Future of Regulation](https://www.frontiersin.org/articles/10.3389/fbloc.2020.00012/full)
|
||||
|
||||
## Open Source Governance Links and Resources
|
||||
|
||||
[How the Node.js Foundation Utilizes Participatory Governance to Build Its Community](https://thenewstack.io/node-js-foundation-utilizing-participatory-governance-models/) - more about opening commit rights to the repo earlier and more quickly?
|
||||
|
||||
[Debian Constitution](https://www.debian.org/devel/constitution)
|
||||
|
||||
[Roads and Bridges](https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/) <- that link is the summary, it is a full eBook
|
||||
[Roads and Bridges](https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/)
|
||||
|
||||
[Governance without Foundations](https://nadiaeghbal.com/foundations)
|
||||
|
||||
[Apache Foundation Governance](https://www.apache.org/foundation/governance/)
|
||||
"The Apache Way - merit, consensus, community, charity"
|
||||
|
|
@ -33,23 +39,4 @@ Similar to a standard corporation.
|
|||
[Wikipedia original statement of principles](https://en.wikipedia.org/w/index.php?oldid=409315229)
|
||||
"Wikipedia's success to date is 100% a function of our open community...Newcomers are always to be welcomed."
|
||||
|
||||
### Blockchain governance
|
||||
(blockchain, because of the inherent ability to count and vote, has a lot of possible governance solutions; most blockchain projects do not actually use blockchain for governance however)
|
||||
|
||||
Dash and Decred are two that may be of interest
|
||||
|
||||
[Decentralized Network Governance: Blockchain Technology and the Future of Regulation](https://www.frontiersin.org/articles/10.3389/fbloc.2020.00012/full)
|
||||
|
||||
concepts: DAOs (decentralized autonomous organizations)
|
||||
|
||||
[Bitcoin and the Rise of Decentralized Autonomous Organizations](https://www.researchgate.net/publication/326816667_Bitcoin_and_the_Rise_of_Decentralized_Autonomous_Organizations)
|
||||
|
||||
|
||||
### Of possible interest
|
||||
|
||||
[SlicingPie - a 'perfectly fair' equity split](https://slicingpie.com/)
|
||||
|
||||
[Gitcoin](https://gitcoin.co/) - bounties for git issues - could include decision making equity
|
||||
|
||||
[Code is Law](https://www.harvardmagazine.com/2000/01/code-is-law-html) - 2000 essay by Lawrence Lessig, not directly applicable but has some important concepts
|
||||
"Information from Bosnia or East Timor can flow freely to the world because the Net makes it hard for governments in those countries to control how information flows....We should interrogate the architecture of cyberspace as we interrogate the code of Congress....Unless we do, or unless we learn how, the relevance of our constitutional tradition will fade. The importance of our commitment to fundamental values, through a self-consciously enacted constitution, will fade."
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
# Moderation
|
||||
|
||||
One of the most acute problems with centralized platforms is the need to develop one-size-fits-all moderation policies for billions of users. Decentralizing social platforms places the power to determine moderation policies in the hands of users or communities.
|
||||
|
||||
## Moderation in federated platforms
|
||||
|
||||
### Matrix
|
||||
|
||||
Servers in Matrix have terms of use that users agree to when they join. Rooms may have moderators who can remove people from individual rooms.
|
||||
|
||||
### Mastodon
|
||||
|
||||
Each server admin can create their own moderation rules as well as a theme for their server. Their TOS may include rules about whether data can leave the server, etc. Users choose which server to join, opting into the moderation policy, theme, and TOS they prefer.
|
||||
|
||||
## Moderation in p2p systems
|
||||
|
||||
## Experiments
|
||||
|
||||
Curation and moderation markets
|
||||
|
|
@ -1,11 +1,14 @@
|
|||
### Messaging Layer Security
|
||||
### Security
|
||||
|
||||
Protocol for end-to-end encryption within large scale messaging
|
||||
Designing for public communication requires less focus on privacy than more intimate social applications. However, privacy for user metadata is still important, and private direct messaging is a feature that may need to be supported.
|
||||
|
||||
Addresses key establishment, authentication, and confidentiality service
|
||||
Some e2e messaging encryption options:
|
||||
|
||||
[Inside MLS, the New Protocol for Secure Enterprise Messaging](https://www.darkreading.com/perimeter/inside-mls-the-new-protocol-for-secure-enterprise-messaging/d/d-id/1335075)
|
||||
- Noise protocol
|
||||
- [Messaging Layer Security (MLS)](https://messaginglayersecurity.rocks/)
|
||||
|
||||
[messaginglayersecurity.rocks](https://messaginglayersecurity.rocks/)
|
||||
### Access Control
|
||||
|
||||
There may be a need for different levels of access to user data - for example, to create read-only applications, paywall, or private sharing.
|
||||
|
||||
Object capability security authorization system
|
||||
|
|
|
|||
Loading…
Reference in New Issue