#SocialWeb #CrazyIdea
Instead of ActivityPub objects all having an absolute URL, they should have a relative URL, that is based on the originating actor.

That would implicitly make each actor it's own namespace (in the sense that DNS is a namespace), and allow easy(-ier) movement of actors between federated instances, by greatly decreasing potential URL breakage.

It could also lead to increased compatibility with future p2p uses of ActivityPub.


That would make URLs non-permanent, isn't that a bad thing?

@doenietzomoeilijk instances are run on volunteer basis, so they're already non-permanent in the sense that any instance in the network can die at any point.
Building a network that requires everything to stay online perpetually makes the network fragile IMO, so I think we should rather design so that we allow some degree of non-permanence.

@doenietzomoeilijk in other words: I don't know? Can we make it work with non-permanent URLs?

On the other hand, how is it going to "know" which user or instance to namespace things under? At some point, that information is going to be added, and I think it's always going to be a bit of an issue when moving.

Maybe there should be a complete "this user has moved" type of activity, which triggers instances to "re-author" all activities they have from that user to point to the new URL. Would result in some messages being out of sync, at least temporarily.

@doenietzomoeilijk if the posts are stored in a format where the instance uses internal ids pointing to actors (which can be taken care of almost for free when receiving the post), then you wouldn't have to change anything in the posts when the actor changes location. The internal actor-id should ideally be unrelated to any other specific attribute of the actor.

Sign in to participate in the conversation

Mastodon-instance voor de Nederlandse gemeenschap, maar open voor iedereen. Voertaal voornamelijk Nederlands en Engels.

Mastodon instance for the Dutch community, but open to anyone. Primary languages Dutch and English.

Maintained by mdbraber@mastodon.nl / Hosting kindly offered by Stek.io and Azure