consider two hypothetical #ActivityPub properties:
-
consider two hypothetical #ActivityPub properties:
- `client`, which signals applications attached to the current actor as activitypub Clients
- `server`, which points to the current service handling the current actor's inbox as an activitypub Serveryour task is to bikeshed these two properties until they make sense. go
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.