Hey everyone
I split my initial post in a number of issues on the new activitypub-interop repo , so that it will be easier to discuss the details. Feel free to create other issues, or comment the existing ones!
The main issue for me is this one about the context of the specification . Please share your thoughts, as I’m not sure where to go from here.
In case you missed it, Vincent Tunrun wrote a nice blog post on his experience of writing a Solid-based ActivityPub client.
@mrkvon Have you been able to work a bit on the ActivityPub agent you planned to do ?
2 Likes
mrkvon
March 5, 2025, 1:58pm
24
Only some testing and research. No meaningful code, yet. This is still high on my list, but I was busy with other work.
I looked at how json-ld looks when it’s produced by CSS, and if it looks anything like the simple format that e.g. Mastodon may expect. (it does not.) There could be a way - having the webId stored as json-ld; but it’s already causing issues - NSS doesn’t authenticate such agent (i suspect it doesn’t ask for text/turtle, and receives the default json-ld instead). CSS seems fine with webId stored in json-ld representation.
Also thought of a name for the project, came up with soap-opera
The most promising intersection of Solid and ActivityPub to me is the general notion of a personal data storage:
(I think AT protocol also provides an excellent real-world use case for Linked Web Storage, but I don’t know how to write up a lws-ucs for it.)
An essential complement to the PDS/Pod paradigm is nomadic identity , which there’s now a complete spec for in NomadPub .
Nomadic identity is a feature that allows users to freely move from one server to another without losing their identities and content.
An extension of ActivityPub protocol is currently being developed that enables nomadic identity and other protocol improvements:
Identity that is not tied to a single server.
Storing user data on multiple servers.
Local-first delay-tolerant applications.
End-to-end encryption.
Implementations of Nomadic ActivityPub can operate in a mode that is compatible with existing ActivityPub server applications.
Specifications
Fedify is working towards this with funding from the Sovereign Tech Agency.
opened 12:02PM - 09 Sep 25 UTC
type/enhancement
### Summary
ActivityPub lacks the ‘credible exit’ featured in AT Protocol, but … its only a few alterations away from the same capability:
From [nomadpub.md](https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md):
> [Nomadic identity](https://joinfediverse.wiki/Nomadic_identity) is a feature that allows users to freely move from one server to another without losing their identities and content.
>
> An extension of ActivityPub protocol is currently being developed that enables nomadic identity and other protocol improvements:
>
> - Identity that is not tied to a single server.
> - Storing user data on multiple servers.
> - Local-first delay-tolerant applications.
> - End-to-end encryption.
> - Implementations of Nomadic ActivityPub can operate in a mode that is compatible with existing ActivityPub server applications.
>
> Specifications
>
> - [FEP-ef61: Portable Objects](https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md)
> - [FEP-ae97: Client-side activity signing](https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md)
One is already being tracked:
- https://github.com/fedify-dev/fedify/issues/288
The other, client-side activity signing, has an open source [reference implementation](https://codeberg.org/silverpill/fep-ae97-client) courtesy of @silverpill
- - -
This would allow me to anchor my apub account in a did-based identity (like `did:plc` in my case) that can be moved to other fep-ef61 compatible instances without identity loss.
References:
- https://github.com/bluesky-social/atproto/pull/3943
- https://socialhub.activitypub.rocks/t/fep-ef61-portable-objects/3738/51
- https://codeberg.org/silverpill/fep-ae97-client
3 Likes