#activitystreams — Public Fediverse posts

In ActivityPub, these are all equivalent:

"type":"Banana"

"type":["Banana"]

"type":{"＠id":"Banana"}

"type":[{"＠id":"Banana"}]

"type":{"id":"Banana"}

"type":[{"id":"Banana"}]

"＠type":"Banana"

"＠type":["Banana"]

"＠type":{"＠id":"Banana"}

"＠type":[{"＠id":"Banana"}]

"＠type":{"id":"Banana"}

"＠type":[{"id":"Banana"}]

#ActivityPub #ActivityStreams #FediDev #JSONLD

What do you think about JSON-LD language maps for "preferredUsername"?

I.e., preferredUsernameMap.

"preferredUsernameMap": {
"en": "hello",
"fa": "درود",
"ko": "안녕하세요"
}

#FediDev #JSONLD #ActivityPub #ActivityStreams

@reiver

Today "ActivityStreams: Where do you want to go to today?" might be a slogan we borrowed from Microsoft.

The question is whether #ActivityStreams should be used - besides all the things it is already being used for - to also map to file systems.

The #LinkedData nature of #ActivityPub is generally shunned in favor of plain #JSON. That in itself is fine, as long as:

a) information still represents valid #JSONLD.

b) information models still follow data modeling best practices.

c) information models are designed with #interoperability in mind.

Not saying your approach is good or bad, just observing that everyone mapping and overloading their own app-specific semantics to the poor AS vocab looks to me a worst-practice. We can get away with it, as we made post-facto interop the poor man's accepted practice, lacking more rigorous extension process and guidance.

There are likely existing standardized ontologies.

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

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

I suspect that there is an error in the Turtle specification, in the section shown in the screen-shot.

(It relates to JSON-LD, which ActivityPub / ActivityStreams is built on.)

I suspect that "PN_CHARS_BASE" is an error.

Because other parts of other specifications seem to not make sense if it is.

I suspect that maybe it should have been "PN_PREFIX" instead.

#ActivityPub #ActivityStreams #RDF #JSONLD

There is a larger discussion about fixed-point numbers versus floating-point numbers.

And that, ALL programming-languages should have fixed-point numbers built into them.

And that, programmers should be warned against using floating-point numbers in all but a set of very specialized situations — where inexact math is OK.

For most programmers in most situations inexact math is NOT OK. And, they should NOT use floating-point numbers.

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259

This is likely (directly or indirectly) the fault of a single paragraph in IETF RFC-7159 / RFC-8259 (shown in the attached screen-shot).

(And note that, there is a difference between JSON and IETF JSON. JSON did not have this. IETF JSON does.)

That paragraph (in the IETF RFC) was NOT a requirement. But, others made it a requirement — including JSON-LD.

RE: https://mastodon.social/@reiver/115956356584464586

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259

This is from the JSON-LD spec.

ActivityPub / ActivityStream are based on JSON-LD.

I think it was a very bad idea for JSON-LD to define "number" this way!

It makes it so numbers with fractional values are inexact & lossy.

This include values that are common for money.

For example, neither 0.10 and 0.20 can be represented exactly. So, 0.10 + 0.20 does NOT equal 0.30!

It should have used FIXED-point numbers rather than FLOATING-point.

#ActivityPub #ActivityStreams #JSONLD #RFC7159 #RFC8259

#ActivityPub, a *great start* providing the key ingredients.

#Fediverse, where things are cooked into a mush, by pragmatic though unsustainable fast-food preparation.

Recipe:

- Mash everything into #ActivityStreams
- Overload the semantic frying pan
- Sprinkle in combinatorial complexities
- Cook until too hot

Then simply keep stirring with increasing whack-a-mole maintenance burdens until project phased out.

Or become the post-facto #interoperability leader and dominate the restaurant chain.

Recipe improvement tips:

- Add #FEP spice to the mix where you can!
- Participate in #SocialCG collective cooking.

@FinchHaven @strypey

I do not think that @naturzukunft2026 misunderstands this.

There's a difference between #ActivityPub the protocol and #fediverse the on-the-wire reality, and in the latter #Mastodon is the post-facto interoperability leader.

For there to be interoperabiity in a particular domain there needs to be agreement on data formats and msg exchanges, and the specs don't provide full coverage nor clear guidance on this. Though #ActivityStreams has a section on use cases it was designed to handle, they aren't fully specified.

Of course it is perfectly fine, and highly encouraged to model a domain in the best possible way, but you won't be "part of the fediverse" until you implement enough of the post-facto Mastodon microblogging interop quirks.

We don't have a good ecosystem-level extension approach, and the #FEP constitutes a best-effort. A bandaid that allows to present a best-practice in hopes it gets further adoption.

I'm not sure that JSON-LD offers solace though.

@eyeinthesky I am genuinely curious. What do you mean by a "real" schema language? What criteria should it meet?

More specifically, what would constitute successful interoperability for #ActivityPub in line with the aims of #SocialWeb?

#JSONLD is not a schema language. It is used to serialise #ActivityStreams as the primary vocab for exchanging social activities, providing a foundation, and leaves room for extensibility for broad human needs to express social matters.

2/

"forgejo" comes from the Esperanto word "forĝejo".

"retejo" is (also) an Esperanto word.

The meaning of the Esperanto word "retejo" can be understood as follows:

ret-: The root for "net" or "web".
-ej-: A suffix meaning "place" or "site".
-o: The noun ending.

https://codeberg.org/reiver/retejo

RE: https://mastodon.social/@reiver/115203527761462559

#ActivityPub #ActivityStreams #codeberg #forgejo #GeminiProtocol #gitea #markdown #retejo #SmallNet #SmallWeb #StaticSite #StaticWeb #StaticWebSite

Teaching ActivityPub and ActivityStreams at University

https://activitypub.rocks/

#Cologne #FOM #DistributedSystems #ActivityPub #ActivityStreams

@cwebber @spritelyinst

After a few years of following your invaluable input, I have to ask whether you've participated in the https://codeberg.org/fediverse/fep community which addresses these very issues?

If not, then why not?

If so, what have been your personally most significant contributions to this #DeSoc and #legacy_silo_averting free namespsce?

Kindest regards,

Bradley

#tallship #FOSS #Fediverse #FEP #lemmur #Spritely #ActivityPub #ActivityStreams #extending #extensions #engagements

⛵

.