consider two hypothetical ActivityPub properties:
client, which signals applications attached to the current actor as activitypub Clientsserver, which points to the current service handling the current actor’s inbox as an activitypub Server
your task is to bikeshed these two properties until they make sense.
if you’re wondering why these properties are needed:
-
the client one hints as to which client-to-client protocols may be used to establish communications. right now, this is probably something like “mastodon protocol” for most actors, but if you want to build a chess app or an E2EE messenger then you can’t expect everyone to understand your activities.
-
the server one hints side effects that will be carried out. in most cases this is something like “activitypub s2s”, but there might be more.
for my part, i think the terms can be made more clear or explicit, for example calling them hasActivityPubClientAttached and inboxManagedByActivityPubServer, but perhaps this is going too far.
also inbox is technically from LDP/LDN and not activitypub, so there probably should be some (re)consideration of the server property