search

w3c / activitypub

http://w3c.github.io/activitypub/
Other
1.24k stars 78 forks source link

"The actor's namespace" #443

Open evanp opened 5 months ago

evanp commented 5 months ago

@trwnh notes in #342 that we specify that the server should create an ID "in the actor's namespace".

"The actor's namespace" isn't a meaningful term in AP. It implies that there are ways to tell which actor created an object by inspecting the ID. Not great!

I believe we need an erratum for this issue.

trwnh commented 1 month ago

revisiting this, it feels like the kind of thing that could actually enable actors to be more portable; by making objects relative to "the actor's namespace", you have the option to treat that "namespace" as a gateway, proxy, or redirector to some final location.

this does seem to require that we give up on "reparenting" objects to different actors, but we could maybe use Move.object == Move.actor instead of Update.object.attributedTo for that. http 3xx can also work as long as the old location's server is up.

at least in a domain-based same-origin-based network, the alternative to "the actor's namespace" is "the server's namespace", i.e. its FQDN (likewise, we assume that a server cannot live in a subpath of a FQDN)

trwnh commented 2 weeks ago

at least in a domain-based same-origin-based network, the alternative to "the actor's namespace" is "the server's namespace", i.e. its FQDN (likewise, we assume that a server cannot live in a subpath of a FQDN)

3.1 Object Identifiers contains this text currently:

Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs).

which maybe should be reconsidered alongside this issue? at least the "authority belonging to that of their originating server" bit. this bit gives the server implicit authority over all objects, which might not be desirable architecturally speaking. an object might be created and given an identifier within "the actor's namespace" to indicate that the object is owned by the actor and not by the server. (this requires the server to be aware of "the actor's namespace", but that's not hard.)

basically if we have a server https://activitypub.example and an actor on that server, we can let the server know that "the actor's namespace" is actually https://trwnh.com/activitypub/ and then it will assign identifiers within that namespace. later when the actor migrates to https://cooler-activitypub.example the ids don't change. the only thing we'd have to do is set up an http url rewriter and redirector from https://trwnh.com/activitypub/ to whatever the current activitypub server is.