2021-05-01 Fediverse Interest Group Meeting

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?

  1. we should all use the generator property of AS

  2. 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 and Object/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 …

  1. When does it happen?
    manually / follow

  2. 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:

2 Likes