devol
/
ecosistema-social-decentralizzato
mirror of https://gitlab.com/bluesky-community1/decentralized-ecosystem.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update mastodon/AP

This commit is contained in:
Jay Graber 2020-07-12 22:34:29 -07:00
parent 263a42f650
commit b9a8227d40
2 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
applications/mastodon.md
View File

@ -16,6 +16,8 @@ Usernames are unique to each instance, not to Mastodon as a whole, so `@alice@ma
If a user moves to a new instance, they can redirect or migrate their old account. Redirection sets up a redirect notice on the old profile which tells users to follow the new account. Migration forces all followers to unfollow the old account and follow the new, if the software on their instance supports this functionality. Previous posts will not be moved.
Since user identities are tied to instances, if [an instance goes down](https://indieweb.org/witches.town), user accounts and data go with it if they are unable to migrate.
Account credentials are managed by the user’s instance, so if users forget their password, they can ask for a password reset. Whether users can delete their own accounts or not is a setting dependent on the instance admin.
For user verification, there is no central authority to check identity documents, but link-based verification can help cross-reference links associated with a user. For example, a user can link to their Mastodon profile from their personal homepage, and receive a verification checkmark on their Mastodon profile by their personal homepage link, to confirm that they are the owner. An identity proof framework was added in 2019, which currently only supports Keybase. It allows users to [link their Keybase cryptographic identity](https://github.com/keybase/keybase-issues/issues/2948) to their Mastodon account.
@ -87,7 +89,7 @@ Mastodon.Social, the instance started by Mastodon's main developer, initially be
When a surge of new users join an instance, server admins can run into scaling issues, as any web host who becomes unexpectedly popular does.
Another scalability issue is the resource requirements of Mastodon. Mastodon hosting providers have emerged as a service to help individuals interested in being admins, but without sysadmin experience, to spin up servers. Pleroma, another federated social app, is advertised as a more minimal implementation good for single user instances that requires fewer resources to run.
Mastodon hosting providers have emerged as a service to help individuals interested in being admins, but without sysadmin experience, to spin up servers.
A [2019 analysis](https://emilianodc.com/PAPERS/mastodonIMC19.pdf) of the Mastodon ecosystem found that the majority of posts are concentrated on a few instances, and outages in 10 instances would remove almost half of all posts from the network.

2
protocols/activitypub.md
View File

@ -8,7 +8,7 @@ ActivityPub consists of two layers: A server-to-server federation protocol, and
Users in ActivityPub are conceptualized as actor objects. Actor to actor communication bears a resemblance to email. To be spec compliant, each actor _must_ have an "inbox" and an "outbox" endpoint, as URLs which are accessible on the server. They also _should_ have "following" and "followers". They _may_ have "liked" collections, and many other predefined possibilities.
[Authentication](https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization): Server to server federation is authenticated using HTTP Signatures. Each actor has a public and private keypair, and a publicly accessible JSON-LD document retrievable over HTTP which contains its public key. Each message the server sends on behalf of an Actor is signed by this key. When a remote server receives a POST to its inbox, it verifies the signature on the HTTP request. To verify object integrity, linked data signatures are used to sign the object with the publicKey of the actor who authored it.
[Authentication](https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization): Server to server federation is authenticated using HTTP Signatures. The server creates a public and private keypair for each actor, and a publicly accessible JSON-LD document retrievable over HTTP which contains its public key. Each message the server sends on behalf of an actor is signed by its key. When a remote server receives a POST to its inbox, it verifies the signature on the HTTP request. To verify object integrity, linked data signatures are used to sign the object with the publicKey of the actor who authored it.
A [paper](https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/final-documents/activitypub-decentralized-distributed.md) from the 2017 Rebooting the Web of Trust conference describes how distributed, cryptographic identities could be added to ActivityPub.