I do wonder about the concept of authority as it relates to these links. I could see an argument that the identifier is actually part of path, since it’s expected to be delegated to a host that is not the originating server (the user’s registered home server). While the https link definitely has the originating host as the authority, the web+activitypub: link doesn’t have a clear authority, it could be opened anywhere.
we wonder if we should just give up…
has anyone looked into these as prior art btw?
At least for the Apple example the URLs do lack an authority, like myphotoapp:Vacation?index=1 (link).
This isn’t exactly the same but it reminds me of how wayback machine forms URLs, eg SocialHub - ActivityPub Special Interest Group
If there were to be a wayback protocol, I would not expect it to use an authority of the site it archived since its archive is the expected handler, eg it might use wayback:https%3A%2F%2Fsocialhub.activitypub.rocks/ or wayback:socialhub.activitypub.rocks/, treating the original URL as a path.
I am not familiar enough with URL standards to have a strong opinion here, just my thoughts.
no, we really do mean these: Supporting associated domains | Apple Developer Documentation
“universal links”, not “custom schemes”.
Hmm I see. I think I’d see this FEP as closer to a custom a scheme than a universal link. There is no known domain that could be registered since any fedi server’s domain could be part of the URL, and there is no known path that could be matched because different projects represent their posts at different paths. (ie /notes/{id} in Misskey vs /notice/{id} in Akkoma). So the client that is registering the protocol is responsible for trying to find the content, regardless of what the path matches. In that way it’s more of a search query than a normal link.
but it’s not.
hypothetically, if https were a chrome thing, how would you expect websites to look?
I see mailto: or xmpp: as closer examples. It’s a bit different I agree, because the path refers to a resource sitting out there on https, rather than just an account name. But that’s what I was trying to get at with the wayback: example. The web+activitypub: link doesn’t refer to the original post, it refers to the federated/stored version of the post on one’s home server.
the way we see it, the federated /stored version on one’s home server is a cache, and one’s home server is the “true” client.
so you’re passing the link onto the “true” client to fetch, the “true” client then fetches it from the actual authority.
but a client is a client is a client, even when it’s on someone else’s server. (have you heard of the concept of a “thin client” before? or whatever you can classify the Opera Mini browser as…)
How will this interact with FEP-ef61?
The linked address MUST replace the scheme used with
web+activitypub:. That means the link MUST NOT simply prependweb+activitypub:onto a preexistinghttps:or other scheme, as this would violate the generic URI syntax specified by RFC-3986
How will the registered handler know whether the encoded link is a classic https:// URL or a new-fangled ap:// or did: URL?
I suppose it could try to parse the “authority” part in both ways, to see which makes sense, but this seems prone to problems. Should this proposal be updated to actually encode the scheme somehow rather than just discarding it?
1 Like
Section 3.1 Retrieving hyperlinked objects:
When retreiving resources identified by a
web+activitypub:scheme, the handler SHOULD assume the origin uses HTTPS. The handler MAY attempt to use other schemes, such asdid:. The handler MAY make this determination using any heuristic or algorithm the developers choose.
I think this FEP is not necessary for ap:// URLs which are by definition associated with ActivityPub protocol (unlike http:// and did:).