Goofed Home

So, an interesting issue came up in the #Fedify repo that I’ve been thinking about: #629.

You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like “Website”, “GitHub”, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Link—and PropertyValue is a schema.org type, not an Activity Streams 2.0 type.

The thing is, we can’t just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it’s technically not spec-compliant.

I’m leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.

What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.

#fedidev #ActivityPub #ActivityStreams #ActivityStreams2 #AS2 #PropertyValue

@hongminhee +1 for formalizing the existing practice in a FEP.

PropertyValue is covered in FEP-fb2a, but it proposes an alternative representation which implementers must support:

https://codeberg.org/fediverse/fep/src/branch/main/fep/fb2a/fep-fb2a.md

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

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" and "sameAs" would be a poor choice. And, 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

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

I used to not like JSON-LD. And then I got exposed to CBOR. And, since then, I ended up liking JSON-LD more than I did before.

https://j12t.social/@j12t/114581086678041245

...

I was looking for performant ways of storing JSON-LD data, so that it can be looked up, queried, etc.

CBOR might actually be a way of doing that.

...

For me that is an odd realization given me liking JSON-LD is a reaction to CBOR.

#ActivityPub #ActivityStreams #CBOR #CBORLD #FediDev #JSONLD

RE: https://w3c.social/@w3c/116216070362563670

FWIW, I have been storing Linked Data (including ActivityPub) in an INI like format — because I find INI-like formats more human-friendly (to both read and write) than JSON.

YAML is probably better than JSON, too, in that respects. But I think INI-like formats are better than YAML.

#ActivityPub #ActivityStreams #JSONLD #LinkedData #RDF #YAML #YAMLLD