1/

AFAIK, there isn't a way for an ActivityPub Actor (such as a Person actor) to specify a list of Service actors associated with it.

...

For example, imagine that there is a Service actor that represents a way to make a video call to me.

And, for example, I have my Mastodon Person actor.

And, I want to let people know about it (and other Service actors associated with me).

How do I do that using AP, etc‽

...

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

2/

Because most people wouldn't be able to add custom attributes or custom values to most Fediverse software (including Mastodon) —

Most supporting software would probably want to support a "PropertyValue" link in "attachment" field as a fall-back

For example:

"attachment": [
{
"type": "PropertyValue",
"name": "Video Calls (callpub)",
"value": "https://videocalls.example/users/joeblow"
}

But —

...

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

3/

But, what about the non- fall-back situation where software could properly support this (when an Actor specifies a list of Service actors associated with it)‽

I think some might say, put the associated Service actors in "attachment". And, semantically I think that would work with ActivityPub, but — I have a very strong dislike with putting everything in "attachment" (and "tag"). It makes parsing difficult.

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

4/

Looking for an alternative to "attachment" (for properly supporting an Actor specifying a list of Service actors associated with it) —

I think using "alsoKnownAs" or "sameAs" would be a poor choice. The semantics are wrong.

For example: a Service actor might represent my mobile phone (or software on it). My phone is not me. It is something I have.

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

5/

Continuing to look for an alternative to "attachment" (for properly supporting an Actor specifying a list of Service actors associated with it) —

I think "endpoints" would also be a poor choice, too. Again, the semantics are wrong, or at least lacking.

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

6/

Continuing to look for an alternative to "attachment" (for properly supporting an Actor specifying a list of Service actors associated with it) —

Maybe a custom top-level attribute would be useful.

Maybe something like:

"service": [
{
"rel":"callpub",
"href":"https://videocalls.example/users/joeblow"
}
]

Although perhaps that is not much better than "attachment", if you just care about calls

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

7/

Continuing to look for an alternative to "attachment" (for properly supporting an Actor specifying a list of CALL Service actors associated with it) —

Maybe a call specific custom top-level attribute would be useful.

Maybe something like:

"call": [
{
"rel":"callpub",
"href":"https://videocalls.example/users/joeblow"
}
]

Or even:

"call": [
"href":"https://videocalls.example/users/joeblow"
]

.

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

@reiver

Though just in hobby time for now I'm thinking about Protosocial protocol, a strict W3C AP-compliant extension that offers an actor-based and service-oriented overlay network, to get solution developers started right away modeling message exchanges and facilitate service composition, orchestration, and choreography.

There's clear division between protocol layer and solution layers that sit on top of it. The protocol uses ActivityStreams as a *reserved* vocabulary to model protocol capabilities and messaging patterns.

The conceptual architecture of the social network is a social graph of addressible actors which exchange activities with an object payload. There's no direct coupling of a Person actor to an actual person's identity. The thought is to have Profile objects serve as identity proofs, and a person can have as many identities as they want.

Actors can be introspected to figure out the service(s) they provide access to, and services encapsulate their design blueprint.

@reiver seems to come into a similar direction as the thought train in your toots above, or did I read that wrong?

@reiver

Perhaps the XMPP specs are interesting to have a look at. Like this XEP specifying a means to do service discovery, and query the capabilities of an entity, and then cache them as a hash: https://xmpp.org/extensions/xep-0115.html

XEP-0115: Entity Capabilities