Preventing enshittification of platforms rests on credible exit for users and devs. #ActivityPub and #SMTP are not perfect but
a) are implemented und understood by many players,
b) enable freedom of choice of servers and clients,
c) implement #RightToMigrate as well as self/community custody
Many #p2p projects promise to remove servers but often promote and depend on a single implementation stack, have no spec and no interop among #p2p islands, and thus struggle to provide credible exit.
@delta
do you see any possible future where we won't need servers? cause yes, having many decentralized instances running on servers is already so much better, but wouldn't p2p be even more decentralized and therefore provide more freedom?
or perhaps the server which hosts an instance (mastodon for example) can be somehow democratized so that all of it's users have a say in the decisions usually made by the admin or moderator 🤔
@delta Activitypub is not designed to be E2E encrypted.
It's better to suggest the nostr protocol because it is E2EE and designed to be censorship resistant.
@silverpill I think Actor should be considered a core type (for the purposes of ActivityPub) just because the whole of the ActivityPub specification is based on it and its structure.
@jwildeboer OK I will be the guy pointing out a typo, but it is because I was very mislead by the "treat-analysis" folder, thinking there may be cupcakes. There were not even cookies. xD
Credits go to @kmh for creating this style. It comes in both a light and dark version (check the links for usage instructions).
If you don't want to fiddle with code and stuff, loma.ml has already installed it server-wide, and should be available straight away for new accounts (If not, go to Settings>Display>General Theme Settings and change it from there. Or follow the guide in any of the links above).
Somebody created a Facebook like UI for Friendica called Bookface (expand for pics&more info)
I'm redesigning my #E2EE architecture to use #OpenMLS instead of Vodozemac. Inertia seems to be with the former and I'd like to see #ActivityPub stay at the forefront.
I should have a working proof-of-concept soon. The big challenge seems to be with persistence; with Vodozemac, I could maintain a separate session record for each conversation. With MLS, all of the Groups are maintained in a single storage object for each user. And that storage is not designed with web server persistence in mind, so I've had to get a little creative. I think I can make it work.
I'm redesigning my #E2EE architecture to use #OpenMLS instead of Vodozemac. Inertia seems to be with the former and I'd like to see #ActivityPub stay at the forefront.
I should have a working proof-of-concept soon. The big challenge seems to be with persistence; with Vodozemac, I could maintain a separate session record for each conversation. With MLS, all of the Groups are maintained in a single storage object for each user. And that storage is not designed with web server persistence in mind, so...
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra.
- End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix.
- Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious.
- Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial).
- Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments.
- Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune.
- Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform.
- Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024.
- Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing.
- URL handlers. No significant progress.
- Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations.
- Markets. No significant progress.
- Quoting. FEP-e232 is now supported by 8 platforms.
- Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial.
- Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61).
- ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar.
- End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop.
- Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra.
migrated a few months old, hardly ever used akkoma instance to pleroma (using database rollbacks from my MR) and it seems to work fine, in case anyone's interested
#ActivityPub objects are JSON documents with a special id property. This property is an URI indicating the location of a document, and we can authenticate a document by fetching its id. If the document exists at the specified location, and has the same ID, we conclude that it is valid.
This has several important corollaries:
1. The server of origin is the only authority. Other servers must not be trusted.
2. ActivityPub is fundamentally a "pull" protocol, not "push".
3. The type of a document is not relevant for authentication. Actor documents are not special.
However, fetching documents is not always practical, and developers may want to push data to other nodes. How documents can be authenticated without making an HTTP request? Digital signatures.
The server publishes a JSON document containing a public key, and then starts signing other documents with a corresponding secret key.
Upon receiving a signed document (such as activity), we determine the ID of a public key document, retrieve the document and verify the signature. If the public key document has the same server of origin as the signed document, and the signature is valid, we conclude that the signed document is valid too, because a chain of trust has been established: received document -> public key document -> server.
The public key document doesn't change often, so now we can verify many signed documents without re-fetching the public key.
This also has important corollaries:
1. Once again, the type of a signed document is not relevant for authentication.
2. Public keys do not need to be attached to actor documents.
3. One key per server is enough.
Developers are constantly being told that ActivityPub is an actor-centric "push" protocol, and that each actor must have its own key. But those ideas are wrong and it is time to put them to rest.
#ActivityPub objects are JSON documents with a special id property. This property is an URI indicating the location of a document, and we can authenticate a document by fetching its id. If the document exists at the specified location, and has the same ID, we conclude that it is valid.
A Call for Better Activity Signatures in the Fediverse
Why Major ActivityPub Implementations Should Adopt Object Integrity Proofs
Let's say you have accounts named alice@bar and bob@baz that don't follow each other, but they both follow john@foo. When alice@bar replies to john@foo's post, how can bob@baz see this reply?
This problem applies not only to replies, but also to things like likes and emoji reactions. One of the ways that ActivityPub implementations solve this problem is through inbox forwarding. The idea is to forward the reply received by john@foo to bob@baz as well.
Because HTTP Signatures sign the HTTP request that contains the activity, not the activity itself, john@foo can't sign an activity created by alice@bar when it's forwarded by him, because forwarding requires creating a new HTTP request. (The HTTP request includes things like the Host header, so a new signature is required for each new recipient.)
So, alice@bar needs to sign her activity in a way that allows john@foo to forward it. In the fediverse, there are two ways to do this: Linked Data Signatures and Object Integrity Proofs. Fedify automatically attaches all three types of signatures (HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs) to every activity it sends, so activities are free to be forwarded between ActivityPub software created with Fedify.
However, major ActivityPub implementations such as Mastodon and Misskey still sign activities with HTTP Signatures only, or only some activities with Linked Data Signatures. (Note that Linked Data Signatures is an outdated standard, and Object Integrity Proofs are recommended.)
So, why are we talking about this at length? We strongly urge major ActivityPub implementations to adopt Object Integrity Proofs, or at minimum Linked Data Signatures, for activity signing!
A Call for Better Activity Signatures in the Fediverse
Why Major ActivityPub Implementations Should Adopt Object Integrity Proofs
Let's say you have accounts named alice@bar and bob@baz that don't follow each other, but they both follow john@foo. When alice@bar replies to john@foo's post, how can bob@baz see this reply?
I am going to implement Conversation Containers instead of inbox forwarding. This mechanism keeps conversations synchronized, but also enables backfilling and moderation of replies.
Existing implementations of Conversation Containers (#Streams and #Hubzilla) add a context property to top-level posts of conversations. This is also what FEP-171b currently prescribes.
However, as I noted in the FEP, this is not consistent with FEP-7888 recommendations. context property is supposed to be used for grouping objects, and in Conversation Containers we have a collection of conversation activities, not posts.
A property that links top-level post to its conversation container should be called differently. For example, threadContext or conversationContext
Note.threadContext == Add.target.id
context can still be used, but for linking to the collection of posts (although I would prefer to use thread for that purpose).
Existing implementations of Conversation Containers (#Streams and #Hubzilla) add a context property to top-level posts of conversations. This is also what FEP-171b currently prescribes.
However, as I noted in the FEP, this is not consistent with FEP-7888 recommendations. context property is supposed to be used for grouping objects, and in Conversation Containers we have a collection of conversation activities, not posts.
Work is still incomplete, but this is the new cover design for the upcoming JP Mitra install guide doujin (with Shadow Wizards courtesy of @ehhh ).
The completed book will be debuted in Onionket 8 next February, and then God willing the physical version will be printed for Summer Comiket C106 in August after that.
The instance type we’d like to host is most likely gonna be @mitra#mitra
..specifically because it supports nomadic identity, so neither our instance nor our users are locked in stasis; Weird net can migrate to a different AP instance in the future if necessary, and instance tenants can migrate to any other instance that supports Nomadic Identity (FEP-ae97), e.g. with:
It’s pretty easy to self-host; the real challenge is instance governance and moderation.
The instance type we’d like to host is most likely gonna be @mitra#mitra
..specifically because it supports nomadic identity, so neither our instance nor our users are locked in stasis; Weird net can migrate to a different AP instance in the future if necessary, and instance tenants can migrate to any other instance that supports Nomadic Identity (FEP-ae97), e.g. with:
Gregory's Server
@delta
do you see any possible future where we won't need servers? cause yes, having many decentralized instances running on servers is already so much better, but wouldn't p2p be even more decentralized and therefore provide more freedom?
or perhaps the server which hosts an instance (mastodon for example) can be somehow democratized so that all of it's users have a say in the decisions usually made by the admin or moderator 🤔
@delta Activitypub is not designed to be E2E encrypted.
It's better to suggest the nostr protocol because it is E2EE and designed to be censorship resistant.
@delta I like #p2p technologies but I think prefer the possibility to migrate between server.
Like #hubzilla