Capability Negotiation
See the Conformance Section of the specification
ActivityPub conformant Client
This designation applies to any implementation of the entirety of the client portion of the client to server protocol.
ActivityPub conformant Server
This designation applies to any implementation of the entirety of the server portion of the client to server protocol.
ActivityPub conformant Federated Server
This designation applies to any implementation of the entirety of the federation protocols.
That was intended, how about reality?
#HowItStarted : NodeInfo
#HowItIsGoing :
grishka:
“… but what if there are different kinds of content?
For example, what if I add photo albums? How would I count these and photos within, or would I ignore them entirely?
The idea of “kind, count” pairs does indeed feel like the way to go.”
[…]
“And this is how we come to the need to have some sort of capability negotiation between servers.
Imagine people hardcoding checks for software names and versions. This can’t end well.”
Can we extend / replace NodeInfo by something better?
-
we should all use the
generator
property of AS -
Let’s define the scope here, Capability Negotiation of
-
the technical feature sets each server or client support
-
the TOS or CoC of the other instance
-
the human values of another user
-
Combination of
Activity
type
andObject
/Actor
type
The most simple approach would be if an instance of any software defines the basic capabilities or ActivityPub subset they support like a combination (Object
|Actor
): [Activity
, Activity
]
{
“Group”: [“Invite”, “Join”, “Leave”, …]
“Place”: [“Arrive”, “Leave”]
}
But it should be per Actor
, for example
"wallPost": ["https://instance.com/users/1/friends"],
"wallPost": ["as:Public"]
Both features could be combined, e.g.
"partyCheckin": {
"Arrive": ["as:Public"],
"Leave": ["https://instance.com/users/1/friends"]
}
Concrete examples were given, for example if you invite other people to a Group …
→ You would like to know if the receipents’ instance will support direct Accept
/ Reject
and if not you can then fallback and e.g. add a link to the original content in a Note
-Invite.
You could also hide the link in your own UI …
-
How do we express support for multiple values (or limits/constraints, e.g. text length) and Multilanguage Support ?
-
How do we express support for
mediaType
s [also html, markdown, boring plain text], see Content, text/plain, and fallback behaviors for limited clients - #4 by melody -
… anything else?
-
When does it happen?
manually / follow -
How do we define “special collections” ?
e.g. immers uses the streams
property via the spec.
“We have a special type model for avatars because [hey ;)] 3D …
You can define your type in your namespace as protocol extensions, for example
smithereen Wall posts = Ordered Collection of Note
immers Avatars = Unordered Collection of Model
redaktor Maps = Unordered Collection of Maps
we could use schema.org
ADD ANY IDEAS HERE !
see also
The ActivityPub Conf Session pad: