Conversation

Notices

1. Embed this notice
   ​ (ta180m@social.exozy.me)'s status on Wednesday, 24-Aug-2022 00:21:38 JST ​

   I wrote a blog post about various #forge #federation myths: https://ta180m.exozy.me/posts/forge-federation-myths/

   As usual, feel free to ask me questions about forge or #Gitea federation!

   • Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 24-Aug-2022 00:23:51 JST Hélène

     in reply to
     @ta180m hello! i do have a few questions!
     will you be using mostly Forge-specific activity types or will you use ActivityStreams core vocabulary? (i'm asking to know if it would be possible to interact from microblogging-related instance software (Mastodon, Pleroma, etc), for example to create or comment on issues, things like that)
   • Embed this notice
     ​ (ta180m@social.exozy.me)'s status on Wednesday, 24-Aug-2022 00:40:22 JST ​

     in reply to

     • Hélène

     @helene we'll be using mixture of ForgeFed types and core AS types. We plan on having features like commenting on an issue with a Mastodon account, but currently Mastodon violates the AP spec by ignoring any ForgeFed types: https://github.com/mastodon/mastodon/issues/18806

     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 24-Aug-2022 00:47:24 JST Hélène

     in reply to
     @ta180m How does this violate AP spec if the type is not supported by the remote server? (I don't remember seeing anything about this in spec, but I'd like to see, so things can be fixed)
     
     Support for those types could be added in Pleroma, though, depending on what the issue is.
     
     ActivityStreams supports using an array on `type` to specify that an activity may be multiple types (using e.g. the supported base activity type first, and the extended type second), which would help servers in understanding activities for types they do not understand.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 24-Aug-2022 01:00:56 JST Hélène

     in reply to
     @ta180m almost every instance fetches to generate an embed!
   • Embed this notice
     ​ (ta180m@social.exozy.me)'s status on Wednesday, 24-Aug-2022 01:00:57 JST ​

     in reply to

     According to my nginx log, 85.49% of the viewers of that post were bots ?

   • Embed this notice
     ​ (ta180m@social.exozy.me)'s status on Wednesday, 24-Aug-2022 04:20:09 JST ​

     in reply to

     • Hélène

     @helene iirc the AP spec required servers to continue processing types that they don't recognize as best as they can. Mastodon could extract the name and content of ForgeFed ticket objects and render them as posts, for instance.

     Type arrays are another solution, but Mastodon doesn't support them and go-ap, the library Gitea is using for federation, also doesn't support them the last time I checked.

     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 24-Aug-2022 04:33:32 JST Hélène

     in reply to
     @ta180m I've been looking at the spec, I don't see much about this. This would be acceptable behaviour for unsupported object types, but this could easily go wrong. I am not a fan of the idea, at all. For example, PeerTube creates a "View" activity for each time someone watches a video. If someone decided to refer to those in an `object`/`inReplyTo`/etc field on their activities, this would be a nightmare.
     
     Type arrays can and should be supported, in my opinion. JSON-LD also has what's necessary for extending types, as well. Issues then come as to how to represent such types (should Repositories really be represented as accounts? how would one star an account from current Mastodon/etc? should Issues be represented as posts? should people be able to hellthread a repo's issues from a social network? emoji reacts?)
   • Embed this notice
     mike (mike@unfediverse.com)'s status on Thursday, 25-Aug-2022 07:02:11 JST mike

     in reply to

     • Hélène
     Methinks you should read the spec again. Implementations are free to ignore extensions they don't know about.  The spec actually recommends  that if you wish to provide an extension  type such as a "Frumble" that can gracefully devolve into and be displayed as a "Note" you identify it as a [ "Note", "Frumble" ]. Some projects will try and display this. If you do this backward and call it a [ "Frumble", "Note" ] or just call it a "Frumble", and we have no idea what a Frumble represents, we've every right to throw it into the bitbucket.
     Hélène likes this.
   • Embed this notice
     ​ (ta180m@social.exozy.me)'s status on Thursday, 25-Aug-2022 07:02:15 JST ​

     in reply to

     • Hélène
     • mike

     @mike @helene Thanks for the correction. I'm actually not working on Gitea-Mastodon interoperability right now, and it was someone else that told me Mastodon was the problem and supposedly violating the spec. Also, Mastodon and go-ap (the AP library Gitea is using) both don't support type arrays, so that complicates any solution involving type arrays.

     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Thursday, 25-Aug-2022 07:16:25 JST Hélène

     in reply to

     • mike
     @mike hello, sorry, completely unrelated question, but: your reply had difficulties federating to Pleroma (it seems like the Create activity was rejected, but not the object itself). Do you have the URI of the Create activity for that Note? Thank you!
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Thursday, 25-Aug-2022 07:32:46 JST Hélène

     in reply to

     • Hélène
     • mike
     @mike Nevermind; found it via your actor's outbox! Thank you nevertheless!
   • Embed this notice
     humanetech (humanetech@mastodon.social)'s status on Thursday, 25-Aug-2022 20:34:31 JST humanetech

     in reply to

     • Hélène
     • ​

     @helene @ta180m

     Yea, I don't think "violate spec" is accurate. #ActivityStreams-core:

     > Consuming implementations that encounter unfamiliar extensions MUST NOT stop processing or signal an error and MUST continue processing the items as if those properties were not present. Note that support for extensions can vary across implementations and no normative processing model for extensions is defined.

     Hélène likes this.
   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Thursday, 25-Aug-2022 20:58:50 JST marius

     in reply to

     • Hélène
     • ​

     @ta180m @helene

     Type as arrays is planned for go-activitypub.

     https://todo.sr.ht/~mariusor/go-activitypub/165

     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Thursday, 25-Aug-2022 22:20:18 JST Hélène

     in reply to

     • ​
     • marius
     @mariusor @ta180m the subject at hand is servers more than clients, and i don't believe it's unreasonable to not process activity types one does not understand, especially considering the examples i've given (and i can give yet more)
   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Thursday, 25-Aug-2022 22:20:19 JST marius

     in reply to

     • Hélène
     • ​

     @helene I think you're working with the assumption that all clients must work with all activity types. That in my opinion is wrong. Doing a "best effort" thing on what a client doesn't understand seems enough to me. Best effort being handling the properties that the client already understands (attributedTo, inReplyto, name, summary, To, CC, samd)

     @ta180m

   • Embed this notice
     ​ (ta180m@social.exozy.me)'s status on Thursday, 25-Aug-2022 22:37:20 JST ​

     in reply to

     • Hélène
     • humanetech

     @humanetech @helene interesting, thanks for the clarification.

     Hélène likes this.
   • Embed this notice
     ​ (ta180m@social.exozy.me)'s status on Thursday, 25-Aug-2022 22:47:17 JST ​

     in reply to

     • Hélène
     • marius

     @helene @mariusor yes, that's right that this is about servers, not clients since Gitea isn't planning on implementing C2S, at least for now.

     @helene for all the examples you gave above, I think they're all reasonable examples of servers processing types they don't understand. For instance treating repos as accounts is perfectly fine because you can follow repos, and treating issues as posts also makes sense so fediverse users can comment on them or even do emoji reacts.

     Hélène likes this.