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:).
+1 to the importance of a logo. I think a name that people can recognize and a unique logo to label the button are key. I thought the ActivityPub logo worked great, here’s an example of how it looked on akkoma-fe.
For web browsers there needs to be a registration flow with the browser (
) so if people saw the same logo when they were offered to register the handler it would be clear what the link means.
1 Like
sorry, but is there a resume of this thread? 
just dropping by wondering how is that state of this, in mdn
this is an upstream thread, for a feature on wordpress-activitypub#1259
great to meet some of you in fosdem 
1 Like
I saw this issue on the Misskey issue board today and I have some concerns over tracking, fingerprinting and de-anonymization.
The proposal said ‘And handling applications themselves MUST apply all the normal and appropriate access controls when retrieving and displaying resources linked this way.’, which I interpret as if any remote fetch is needed, the public key of the user’s actor would be used.
I think there is a good reason we don’t have just a web+search://my+search+term functionality in web browsers.
Technically we can argue that people need search engines every day, and everybody use different search engines so we should have a protocol handler that just dispatches to the user’s preferred search engine.
It isn’t done in reality for a reason IMO, (1) it is not just open redirects there also is fingerprinting and other information leakage concern (2) users still want flexibility, some people use multiple search engines / instances at once, some people want to vet the user or instance first before viewing a resource that could be illegal, etc.
For example I can just add a link to web+ap://my.tracking.example , and monitor which instance looked up my post, and what kind of HTTP signature are attached to track who viewed this (the keyId will encode the User ID), and correlate this with what IP was visiting the page hosting the link (which I control too). I did not see the proposal (either on the FEP or fedilinks.org) discuss considerations in this realm.
At the very least originally the tracker need to predict my instance first and give me a link like https://my.instance.example/@tracked@tracking.example, so they know (1) the IP that loaded the page that hosted the link (2) the public key that signed the later fetch request, now they can systematically track every clicker of that link with a valid Fediverse session somewhere on the device, by just just using web+ap://tracking.example/@tracked or semantic equivalents.
This defeats the purpose of things like media proxy in Misskey. At the very least this /protocol-handler implementation should never sign any remote fetch requests.