I’m trying to find out where the development is at right now for ActivityPub, specifically about data (posts) portability, and persistent IDs.
For the former I think that’s fairly self-explanatory, I’m just trying to get a flavour of if it’s a priority, who’s working on it, what the anticipated timeline is etc. It’s a clear advantage that ATproto has, so are we trying to close the gap?
By the latter I mean is there work happening to work towards us being able to have one ID that can be used to log in to any fediverse network (as per nostr)? This approach makes so much sense to me - is it even possible?
The link here to W3.org doesn’t seem that up to date - but I’m not that knowledgable so may have misinterpreted that site. So I’m looking for education on this subject 😊
@Paddy66 The work on data portability is documented in this Fediverse Enhancement Proposal (FEP):
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
You can find the list of implementations there (built by me and @mikedev).
For logging with a single ID into multiple apps, standard ActivityPub Client-to-Server API can be used, but I don’t know any production-ready application that utilizes Client-to-Server API in such way.
The alternative is this FEP:
https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md
It’s a re-design of Client-to-Server API based on FEP-ef61.
e.g. there’s this https://swicg.github.io/activitypub-data-portability/ - is that being looked at by the people developing the protocol?