Gregory's Server@ta180m @caesar type arrays aren't in the ap spec, they're in the json-ld spec, it should be supported (but isn't)
the file you wanna look at https://github.com/mastodon/mastodon/blob/main/app/lib/activitypub/activity.rb
|
14 comments
 @humanetech @trwnh @caesar Ah, interesting, so it is in the spec. In that case, the real problem is that existing AP software don't support type arrays, so if we used the solution of type arrays, we'd also have to send PRs to Mastodon and the others.  @ta180m @humanetech @caesar the PRs should probably happen anyway, but the type array isn't strictly necessary IMO because marking a Ticket additionally as a Note doesn't really provide any additional benefit, does it? Multi-type stuff is useful mostly for multiple vocabs/contexts. @trwnh @humanetech @caesar Yeah, type arrays were just an alternate solution we thought of, but for now we're going to go with sending Mastodon a PR to run the conversion logic on all types instead of just the few hardcoded ones.  Go activitypub will support types as arrays at some point. I'm not entirely sure of how the API will look, but it will be there in some form. In my opinion, providing a "fallback" type for certain objects can be good for interoperability with other services. Eg, an "Issue" object can have a fallback as a "Note" where a random mastodon instance will show just its text content, and minimize breakage. (if mastodon would accept array types that is :D) @mariusor @ta180m @caesar mastodon already has "fallback" logic for using the `context` as status text if available, and `name` if not, combined with `url` the problem is that this fallback logic is only applied to specific types -- for whatever reason, it doesn't get applied if the type is unrecognized. imo this is a bug that should be fixed @trwnh From my recollection the the spec recommends that the first element be a common type if you are able to provide that rendering. The second one can then provide custom or implementation specific variations. If we can't display 'Blob' we're not even going to try to render a [ 'Blob', 'Note' ]. But we'll happily render a ['Note','Blob']. Anyhow that's how I interpreted it. I think we'll store and forward it regardless.
 @trwnh @ta180m @caesar @humanetech addendum; PS @trwnh @ta180m @caesar @humanetech I just wonder where these misconceptions come from. - "id" in AP is only an Alias for JSON-LD's "@id" - "type" in AP is only an Alias for JSON-LD's "@type" So, "id" must be 1 URI and "type" must be a Set (or unique Array). The idea behind that was _just_ to make it easier for JS users cause old ES versions didn't allow "@" for dot notations, see Mathias' nice tool https://mothereff.in/js-properties#@type |
@trwnh @caesar Ah interesting. Sometimes it doesn't even matter what the AP spec says, but actually what servers do in practice, and I haven't seen any AP implementation ever that supports type arrays.
I'll take a look at the Mastodon code later and submit a PR, since for now we are focusing on Gitea<->Gitea federation.