Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Saturday, 13-Jun-2026 04:44:30 JST silverpill

   • Beady Belle Fanchannel
   • grindhold

   @sabrinkmann Why create different versions when you can use one?

   There are ways in which the Fediverse can accomodate the greater number of different services:

   - Content negotiation: every server advertises supported types, and the sender needs to adjust activities depending on what the recipient understands.
   - Duck typing: recipients don't filter received objects by type, and instead look at their properties.

   I don't think the first approach can work at scale. It's like serving different websites to different web browsers.

   (Negotiation can be useful in some cases, though - I even wrote a FEP about this: https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md)

   @Profpatsch @grindhold

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 04:00:52 JST silverpill

     in reply to

     • Beady Belle Fanchannel
     • grindhold

     @grindhold

     e.g. we had this situation where content was defined as a Proposal as string, whereas in Note it was common to have a mapping from lang-code to a string in the according language as content.

     I'm not sure if I understand. Mapping from lang-code to string it not content, it's contentMap: https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues.

     Proposal was designed with duck typing in mind. Proposal.content is same as Note.content, Proposal.attributedTo is same as Note.attributedTo. If everyone designs their extensions this way, duck typing works great.

     The conflicts might occur but the solution to this is to use better names. So far I seen only one conflict: between Bookwyrm's quote and Mastodon's quote. In such cases you can use type for disambiguation - I am not saying that we should drop type completely. Ironically, though, Bookwyrm does use content negotiation. When it thinks that remote server is not Bookwyrm, it sends a Note instead of the original type, Quotation, thus making disambiguation impossible.

     That's exactly how content negotiation will work in practice.

     @sabrinkmann @Profpatsch

   • Embed this notice
     grindhold (grindhold@23.social)'s status on Sunday, 14-Jun-2026 04:00:53 JST grindhold

     in reply to

     • Beady Belle Fanchannel

     @silverpill @sabrinkmann @Profpatsch when the fediverse and the FEP-database gets bigger the need to check for these conflicts will rise quadratically. So you either:
     - need to include type-definitions for fields with specific names
     - use ap-object-types
     or
     - end up with incompatibilities and accept that as a fact which leads to bloaty (and potentially slow) unmarshalling logic on the implementation side.

   • Embed this notice
     grindhold (grindhold@23.social)'s status on Sunday, 14-Jun-2026 04:00:54 JST grindhold

     in reply to

     • Beady Belle Fanchannel

     @silverpill @sabrinkmann @Profpatsch

     the biggest problem with the duck typing approach imo is, that there might occur situations in which different definitions exist for the same field.

     e.g. we had this situation where content was defined as a Proposal as string, whereas in Note it was common to have a mapping from lang-code to a string in the according language as content.

     In this case we could figure it out but there might be more complicated cases and not every type might end up mixable

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 23:25:37 JST silverpill

     in reply to

     • Beady Belle Fanchannel
     • grindhold

     @Profpatsch @grindhold @sabrinkmann I support vendor prefixes.

   • Embed this notice
     Beady Belle Fanchannel (profpatsch@mastodon.xyz)'s status on Sunday, 14-Jun-2026 23:25:39 JST Beady Belle Fanchannel

     in reply to

     • grindhold

     @grindhold @silverpill @sabrinkmann I think we should at least use a system that’s somewhat resistant to semantic overload, like CSS vendor prefixes.

     e.g. add "flohmarkt:foobar" as a new field, and when it receives an FEP you can drop the prefix. So “on the edge” software can start by using the prefixed field, and then slowly migrate to unprefixed FEP once that’s there.

   • Embed this notice
     grindhold (grindhold@23.social)'s status on Sunday, 14-Jun-2026 23:25:40 JST grindhold

     in reply to

     • Beady Belle Fanchannel

     @silverpill @sabrinkmann @Profpatsch in this particular case you are right. in the general case, as the fediverse is a decentral system, it might occur, that developer group A creates APObjectTypeA with a field named "foo" that does a specific thing. developer group B will create APObjectTypeB with a field named "foo" that does another thing. these object types will not be composable. as only one meaning of "foo" can exist simultaneously in a specific object.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 16-Jun-2026 02:17:10 JST silverpill

     in reply to

     • Beady Belle Fanchannel
     • grindhold

     @grindhold

     >how about type-specific prefixes like e.g. "proposal:foobar".

     That's fine too IMO. The probability of collision is higher compared to vendor prefixes but not much.

     @Profpatsch @sabrinkmann

   • Embed this notice
     grindhold (grindhold@23.social)'s status on Tuesday, 16-Jun-2026 02:17:11 JST grindhold

     in reply to

     • Beady Belle Fanchannel

     @silverpill @Profpatsch @sabrinkmann
     so people, if they develop extensions to AP would at least be forced to think about how to integrate their stuff into the existing AP-ontology. at least thinking about where they need a new type, what fields it needs .e.t.c.

     i mean, we did the vendor-prefix thing with flohmarkt. because i saw no other way and i found it ugly from the start :D (and i hadn't had the idea to pack a non-Note-object into an attachment yet)

   • Embed this notice
     grindhold (grindhold@23.social)'s status on Tuesday, 16-Jun-2026 02:17:12 JST grindhold

     in reply to

     • Beady Belle Fanchannel

     @silverpill @Profpatsch @sabrinkmann

     i think vendor prefixes is a fad too specific. how about type-specific prefixes like e.g. "proposal:foobar". if you give single vendors the possibility to mess with the standard it'll end with everybody cooking up their own soup. and maaaybe if you're lucky, one of them becoming the de-facto standard, totally bypassing what AP wants to achieve: a common protocol for all to agree on.