Another one for the #mastoquirks pile, inReplyTo can't be an array in Mastodon land despite that being allowed in the ActivityStreams vocabulary/JSON-LD representation.
Searching for objects on the federated.id server, which are replies to something else, results in internal server error in #mastodon. :(
Opening bug as we speak, but I have little hope.
I keep being on a roll today. I discovered the mystery of why #BrutaLinks doesn't show follows coming from Mastodon.
It actually does, but because they don't have a published date they are ordered at the end of the inbox, so I had to go all the way to the end of the listing to find them. Sigh...
Another one to put on top of the pile of #mastoquirks
@helge is this just for Create activities? It wouldn't make sense for the other types. Even for Creates, it's a bad heuristic which (I imagine) tries to optimize the cases where bad actors are trying to take credit for creating objects they don't own.
I can see plenty of use-case where decoupling the activitypub server from the object storage server makes sense.
So, this is another one to add to the pile of #mastoquirks . :(
Forgot about this in the four days I was out sick.
Anchors are not the secret sauce that should make your URLs unique @Mastodon!!
Forgot about this in the four days I was out sick.
Anchors are not the secret sauce that should make your URLs unique @Mastodon!!
Another issue regarding Mastodons quirks: Undos are referred to as .../users/mariusor#follows/{id}/undo
o.O
The ActivityPub spec requires unique IRIs for all objects. According to MDN (emphasis mine):
> An anchor represents a sort of "bookmark" **inside** the resource, giving the browser the directions to show the content located at that "bookmarked" spot.
So, relying on anchors for uniqueness is incorrect.
Another issue regarding Mastodons quirks: Undos are referred to as .../users/mariusor#follows/{id}/undo Mastodon?!?!? o.O
The ActivityPub spec requires unique IRIs for all objects. According to MDN (emphasis mine):
> An anchor represents a sort of "bookmark" **inside** the resource, giving the browser the directions to show the content located at that "bookmarked" spot.
So, relying on anchors for uniqueness is incorrect.
My hope of having #FedBOX interacting fully with Mastodon by the end of the year is wholly shattered as they don't support HTTP Signatures generated with anything other than RSA256 keys. For a moment I was hopeful that HS2019 was a solution to that, but sadly no, even when using it, Mastodon expects that the keys are RSA256.
There are discussions about adding support for more modern ones like ed25519, but no input from the devs so far. :(