|
Top-level
 @ta180m Cool! In response to your points: 1. I assume I wouldn't need to interact with a Gitea UI to comment from Mastodon or another fedi app? 2. I guess I assumed that by being an ActivityPub extension, basic features like following and replying would be automatically interoperable - is that not the case? 3. Ah, I guess that's probably the main reason then? (I need to familiarise myself with the specs more. As you can probably tell I don't know a lot about ActivityPub...) 26 comments
 @caesar 2. The problem here is that issues are represented using the ForgeFed type Ticket, which Mastodon doesn't understand. The ActivityPub spec states that AP servers should continue processing an activity that they don't recognize, but Mastodon doesn't seem to care about spec compliance and bails out when it sees a Ticket. 3. Actually, the second reason is the most difficult to address, since we'll need to contribute a fix to Mastodon. The third reason as I said is easy to address.  @ta180m @caesar mastodon has a transformer for non-Note and non-Question activities, it just takes the `name` and `url` fields and joins them together (or uses `content` if available) to generate the status. https://docs.joinmastodon.org/spec/activitypub/#payloads you could theoretically just remove the type-checking from that bit of code? @trwnh @caesar Yeah, it looks like we'll probably have to submit a PR to Mastodon to fix this. We thought of a few alternate solutions but they aren't very nice or don't work: @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 @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. @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 @ta180m@exozy.me Thanks for the replies! @ta180m@exozy.me I should note that it's showing as waiting for @Ta180m@git.exozy.me to accept a "follow request". Is that intentional? @caesar @Ta180m@git.exozy.me That's probably a bug. My recent commits for federated commenting may have broken following. @caesar @Ta180m@git.exozy.me The reason that works is because I believe Mastodon serves the ActivityStreams objects at the same URL that you see them in a web browser, based on if the Accept: application/activity+json header is set. For Gitea we're serving the AS objects at some endpoints under /api/v1/activitypub. @caesar We currently don't serve the issues as AS objects at any API endpoint, but in the future they should be accessible at /api/v1/activitypub/issue/username/reponame/issuenumber or something like that. For your other question: Great question, since I currently only run Mastodon and PeerTube instances, so I haven't tried federating any other AP servers with Gitea yet. @ta180m 2. Ah, so it's @Mastodon that's not following the spec. Definitely sounds like a PR to fix that would be great, though obviously Gitea<–>Gitea federation is the priority. (Like you, I'm not a fan of the other workarounds you suggested in your other comment). While I'm here, thanks for all your work on forge federation! This is going to be @gitea 's killer feature 🚀 |
Gregory's Server
@caesar 1. In theory yes, you could just directly paste the issue's IRI into Mastodon's /authorize_interaction?uri=. However, Mastodon has a UI for automating this: when you're on a remote instance and want to interact with something, there's a popup box where you can type in your instance and you're redirected to the authorize_interaction page automatically. We need to implement something similar in Gitea.
I'll continue my response to the other points in a reply: I'm at the character limit...