Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @sabrinkmann@hachyderm.io
silverpill@silverpill@mitra.social (2026-06-13 04:30:14)
@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
---Reply---
grindhold@grindhold@23.social (2026-06-13 20:20:30)
@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

---Replies---

grindhold@grindhold@23.social (2026-06-13 20:23:12)
@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.