Re: Alternative identifiers for ActivityPub objects

The main concern is the dereferenceable IDs we use for ActivityPub objects,
and the locations for binary objects that we use Link href values for. Two
main use cases came up in that discussion:

1. Discontinued servers. If an object has an ID like
https://social.example/note/1 , and server social.example goes offline
permanently, it's impossible for other servers to dereference the ID again.
Specifying an alternate/archived location for the object would give some
continuity of service.
2. Lowering the load on small servers. If an object has an ID like
https://social.example/note/1 , and social.example is on a small server,
sudden increase in demand for the object could overload the server.
Specifying fallback or alternative locations for the server can let remote
servers use the alternative and lower the load on the main server.
Similarly, the binary content for an Image, Video, Audio, or Article object.
3. Protocol experimentation. A new protocol foo: is defined. ActivityPub
server implementers want to experiment with serving ActivityPub objects
through that protocol, but they don't want to commit to the protocol fully
while the rest of the Fediverse depends on https: . They want to stay
connected. It's great for these servers to have a way to specify foo:
locations for an object to foo-aware servers, and let others use the
default HTTPS location.
4. Bridging. An object in the ActivityPub ecosystem has an equivalent in
another ecosystem (Nostr, ATProto, Diaspora, ...). Declaring an equivalent
ID can help servers deduplicate objects ("The object I received from bridge
1 represents the same object that I received from bridge 2.")

I think a non-goal here is to pick a specific winner for alternative IDs
and alternative storage -- magnet: URLs, ipfs, dids, freenet, gnunet,
bittorrent. I think it's much better to provide a framework for
experimentation. I think it would be good to answer questions like, "How
could I use IPFS to store duplicates of an image, and declare the location
of those duplicates in the Activity Streams object?"

Evan


On Wed, Sep 2, 2026 at 7:03 PM Bumblefudge <bumblefudge@learningproof.xyz>
wrote:

> TLDR; don't put the cart before the user-story set :D
>
> Longer version:
>
> I think we are mixing two fairly different streams here, namely, editorial
> changes to the v1 spec that alter behavior around object and/or actor
> identifiers, versus CG work on new handle and account affordances.
> Furthermore, in both cases I worry we might be jumping to technical
> solutions without reaching consensus on what the problems are, much less
> their relative priority.  As I have in all other recent conversations about
> task forces and reports/notes, I will here as well request use-case
> documentation and consensus on that documentation BEFORE any collaborative
> design work on solutions that expects to get CG consensus down the road!
>
> How about a special-topic call+email thread (happy to hijack this one)
> where people discuss use-cases and user-stories, and if there is consensus
> on a core set of user stories, a task force or series of special-topic
> calls could be initiated that weighs multiple solutions against that set?
>
> Confession: I have actually been working for months on some use-cases and
> prototypes that touch on these topics, but I was waiting to hear from
> others what user-stories *they*​ were looking to enable for users of AP
> software before sharing those with the group. I also wrote up some related
> content-addressing use-cases in 2024 [^1], and am hoping to start a
> content-addressing FEP soon that addresses some of the user stores in my
> other user story document from 2024 [^2]. These last user stories,
> gathering feature requests from various corners of the Fediverse for the
> Portability Task Force, included a few that can't really be solved
> *without* content-addressing and other fancy identifiers and data
> structures, so this topic is something like my personal Rosebud.
>
> I'd be happy to lead or frame a discussion about any user stories across
> these various past and future documents, and I'd be even happier if others
> brought their totally unrelated user stories into the mix.
>
> Thanks,
> __bf
>
> [^1]: https://fediverse.codeberg.page/fep/fep/cd47/
> [^2]: https://fediverse.codeberg.page/fep/fep/73cd/
>
> ---
> bumblefudge
> interim tech lead, @Decentralized Identity Foundation
> <https://identity.foundation>
> contractable via learningProof UG <https://learningproof.xyz>
> mostly berlin-based
>
> On Wednesday, September 2nd, 2026 at 10:44 PM, Melvin Carvalho <
> melvincarvalho@gmail.com> wrote:
>
>
>
> st 2. 9. 2026 v 22:06 odesílatel Evan Prodromou <
> evanp@socialwebfoundation.org> napsal:
>
>> Hey, all! One topic that has come up in the working group is how to
>> define alternative identifiers for ActivityPub objects:
>>
>> https://github.com/w3c/activitypub/issues/601
>>
>> I think the best structure for us is a framework supporting alternative
>> ids in an ActivityPub object or link: recommend a default HTTPS identifier
>> or href, and allow one or more alternative identifiers or hrefs. We have a
>> few good options, and we'll need to reach a conclusion on it soon.
>>
>> But we also have significant interest in specific alternative identifier
>> schemes. Christine Lemmer-Webber started a conversation on
>> content-addressed ActivityPub messages:
>>
>> https://github.com/w3c/activitypub/issues/573
>>
>> There has also been a lot of interest in using DIDs for AP objects and
>> links.
>>
>> I'd love us to have a way to explore these options in the CG. At the very
>> real risk of task force fatigue, would it make sense for us to start a task
>> force on alternative ActivityPub object ids? Alternatively, would this fit
>> into one of our existing task forces, like Handles or API or Data
>> Portability?
>>
>
> We've done quite a bit of work in the W3C Nostr CG on the social use case
> with DIDs. This website may be some food for thought:
>
> https://did-nostr.com/
>
>
>> Evan
>>
>
>

Received on Thursday, 3 September 2026 20:34:01 UTC