-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ActivityPub ids with # symbol are not resolvable #13879
Comments
Related to friendica/friendica#8700 |
These URLs aren't intended to be resolvable currently, yes. We created unique identifiers in this case to encourage compatibility with some other integrations that wanted Likes to be uniquely identifiable. However, i don't think saying that fragment URLs in general aren't resolvable is correct—to resolve an identifier like |
You make a valid point, however multiple |
I think we only put one |
@koehn yeah, you're correct, the Likes in question are intentionally non-resolvable since we haven't built that, but we added a unique One security concern that makes things a little complicated here is the possibility of enumeration. We definitely don't want to make user's likes enumerable. @koehn if the likes endpoint was unique, but returned a 403 for anyone except the user whose content was liked, would that work for you? (not saying we're going to build that, just wondering about your use-case) |
Null-IDs are not desired because then managing the undos becomes impossible if they arrive out of order. |
@Gargron it's stilo possible, but it does get slightly more complicated. I would do something like:
So if, for example, you get 3 deletes followed by 2 likes, you'll end up at -1, and never create a Like object. (this does remove the ability to distinguish between retransmission of old events and new events, but we could handle that by including another high-entropy property, like created_at with millisecond precision, and go back to the old single-boolean key algorithm) |
My use case is this:
Honestly the way that this gets federated is bizarre to me (it seems that User B's server should be sending the |
FWIW this is a lot simpler in an NoSQL database. |
Hmm.... what is the audience of the I don't know what people's current expectations of privacy are around Likes and I wouldn't want to introduce something that would violate those expectations by showing them to a third party without first providing users with more explicit privacy toggles |
See also #13571 |
this is still underspecified and a bit inconsistent across fediverse implementations: https://socialhub.activitypub.rocks/t/problems-posting-to-mastodon-inbox/801/11 > The reason might also be that your IDs aren’t permanent, as in, they contain a #fragment. Posts and their corresponding Create activities are supposed to be resolvable — which means one should be able to send a GET request to the ID URL and get the object back. This can’t be done with an URL that contains a fragment as the fragment is not a part of the HTTP exchange, it’s processed on the client. https://socialhub.activitypub.rocks/t/problems-posting-to-mastodon-inbox/801/23 > I ran into this object id #fragment problem as well. It seems because of some URL normalization, Mastodon will remove the fragment, and drop any additional posts with different fragments (because they become the same url). https://socialhub.activitypub.rocks/t/s2s-create-activity/1647/5 mastodon/mastodon#13879 (open!) w3c/activitypub#224 nothing in the http sig spec, example key ids aren't even URLs there: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-16
Expected behaviour
Per the ActivityPub specification, IDs must either be
null
or:Actual behaviour
Mastodon ids include information in the fragment (
#
) section, which renders the portion of the ID beyond the fragment symbol as unresolvable by HTTP-conforming libraries such as libcurl.Steps to reproduce the problem
curl -vH 'Accept: application/activity+json' 'https://mastodon.technology/@norztech#likes/836349#Like'
curl
(correctly) sends:The text was updated successfully, but these errors were encountered: