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 Server

your task is to bikeshed these two properties until they make sense. go

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

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.