What if we had a P4 for ActivityPub?
Technical Discussion
2
Posts
2
Posters
1
Views
-
P4 is a system-independent programming language for network devices like switches and routers. It lets developers define device behaviour like forwarding packets, quality of service, and traffic shaping. It's event-based; it defines what the device should do as it receives packets on a network interface.
What if we had a similar language for ActivityPub servers? You could define rules for what to do when different Activity objects hit an
inboxoroutbox. It could be defined to implement the basic flows in the ActivityPub specification, likeFollow/Accept/Reject/UndoandCreate/Update/Delete. But it could also be used to define other protocols, like geosocial interactions, groups, and events. Unlike P4, it would need to deal with persistent storage, but otherwise it could be quite similar.I think some servers have a milter-like programming interface. Pleroma, maybe? It would be interesting to generalise support for that, or something similar, into a general-purpose high-level social programming language.
-
This does exist, Pleroma has the Message Rewrite Filters or MRF functionality. There's also ActivitySieve or ActivityColander I think it was called, which attempted to do similar.
I've personally been arguing that we need federation management via policies more akin to a firewall: https://writings.thisismissem.social/moving-beyond-the-false-dichotomy-for-federation-management/
Gli ultimi otto messaggi ricevuti dalla Federazione
-
If we're going to be publishing activities regarding resolvable context collections then it may be time to introduce a new object type.
It would be backwards compatible with f228 OrderedCollections... using the new type would signify support for the various activity types perhaps...?
Edit: if this is what you were proposing with client managed collections, then my apologies 😅 the naming threw me off
-
Another solution: introduce a new object class, client-managed collections. These collections should have a property that differentiates them from server-managed collections, e.g. isClientManaged: true. And they shouldn't be paginated.
I think this would be compatible with client-side signing.
But companion object solution seems to be cleaner.
-
@julian that might be it, yeah. languages outside of javascript generally don't make a distinction between null and undefined, and even in javascript these are used inconsistently. for example localStorage.getItem will return null for a missing key. practically speaking, the "intentionally" distinction is a distinction without a difference in most processing contexts.
-
trwnh@mastodon.social undefined and perhaps that's why we're disagreeing on our interpretations of how these values should be handled.
null in JavaScript is very explicitly a declaration that there is no value or "intentionally empty".
null and undefined are two separate things here at least.
-
@julian what does js return instead? in most cases i'm familiar with, programming languages use null or nil or None for anything that doesn't have a value, or any reference which doesn't point anywhere. hence a null pointer exception when you try to dereference a null. if you try to get a value for a key that isn't in the dictionary, you get null by default because there is no value for a missing key. how would you consume a null value? if you have nothing to say, why say anything?
-
trwnh@mastodon.social I'm coding in js, which has all sorts of footguns, but even that won't return null when I attempt to access the non-existent property of an object... 😛
-
@julian this wouldn't be your AP lib, it would be your programming language itself
-
trwnh@mastodon.social as someone working on the consuming side, that is not correct.
If my AP lib automatically assumed null when requesting an object property that didn't exist I'd consider that a bug.
