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

grindhold@grindhold@23.social

Developer of the ActivityPub Software Flohmarkt.

Imaginäres Institut für Generaltechnologie

KRW
BBR
Joined: 2026-06-14 04:02:40
3 notes, 0 following, 0 followers

Reply to @silverpill@mitra.social
grindhold@grindhold@23.social (2026-06-14 19:48:46)
@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.

Reply to @grindhold@23.social
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.

Reply to @silverpill@mitra.social
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