Post · bonfire.cafe

@kopper@not-brain.d.on-t.work replied · 4 hours ago

@hongminhee@hollo.social from the point of view of someone who is "maintaining" a JSON-LD processing fedi software and has implemented their own JSON-LD processing library (which is, to my knowledge, the fastest in it's programming language), JSON-LD is pure overhead. there is nothing it allows for that can't be done with

making fields which take multiple values explicit
always using namespaces and letting HTTP compression take care of minimizing the transfer

without JSON-LD, fedi software could use zero-ish-copy deserialization for a majority of their objects (when strings aren't escaped) through tools like serde_json and Cow, or System.Text.Json.JsonDocument. JSON-LD processing effectively mandates a JSON node DOM (in the algorithms standardized, you may be able to get rid of it with Clever Programming)

additionally, due to JSON-LD 1.1 features like @type:@json, you can not even fetch contexts ahead of time of running JSON DOM transformations, meaning all JSON-LD code has to be async (in the languages which has the concept), potentially losing out on significant optimizations that can't be done in coroutines due to various reasons (e.g. C# async methods can't have ref structs, Rust async functions usually require thread safety due to tokio's prevalence, even if they're ran in a single-threaded runtime)

this is after context processing introducing network dependency to the deserialization of data, wasting time and data on non-server cases (e.g. activitypub C2S). sure you can cache individual contexts, but then the context can change underneath you, desynchronizing your cached context and, in the worst case, opening you up to security vulnerabilities

json-ld is not my favorite part of this protocol

Sebastian Lasse

@sl007@digitalcourage.social replied · 1 hour ago

@kopper
@julian
@hongminhee

hm, we really need to differentiate between users responsibility and dev responsibility.

Not sure if Hong saw the draft about the AP kv thing, it supports either JSON-LD fields _or_ as:attachment / as:context …
wtf do I want to say.

user story:
We are working on 2 major and 3 projects fulltime which is
- federation of wikibase / wikidata
- federation of Public Broadcasters https://www.publicmediaalliance.org/public-broadcasters-create-public-spaces-incubator/
and these https://codeberg.org/Menschys/fedi-codebase

Let's say we want to federate a Country, then all the knowledge is sent in `attachment` with the fully qualified qikidata url in `context` [as:context - not @context ! - this is so confusing :)]
For example the according entries from the PressFreedomIndex `collection` (co-founder of freelens here :)

But anyway, the idea about having
"wd": "https://www.wikidata.org/wiki/Special:EntityData/",
"wdt": "https://www.wikidata.org/prop/direct/" in the `@context` was that any user can consume and federate wikibase
incl.
🧵 1/2

Entity Data - Wikidata

Codeberg.org

fedi-codebase

meta-repo keeping track of the unified codebase for the ActivityPub Clients menschys. taxiteam and redaktor.

Public Media Alliance

Public broadcasters create "Public Spaces Incubator" - Public Media Alliance

Four public broadcasters are partnering to develop solutions to address increasingly toxic, polarized and unsafe online discourse.

Sebastian Lasse

@sl007@digitalcourage.social replied · 1 hour ago

@kopper @julian @hongminhee

incl.
- the properties in all the languages of the world
- the knowledge of the world in all the languages
- the wikidata relations and qualified statements including the nameMap etc. and all the urls to all wikiprojects incl. their languages and knowledge

How else could I say to other softwares if they want all users qualified data, use wikidata vocabulary?
wikipedia, wikidata, EBU, Public Broadcasters, taxi data is _all_ JSON-LD …

kopper :colon_three:

@kopper@not-brain.d.on-t.work replied · 45 minutes ago

@sl007@digitalcourage.social @hongminhee@hollo.social @julian@activitypub.space i feel like you're falling into a trap i've seen a lot around AP spaces: just because the data can be contorted to represent something does not mean software will interpret it as such.

any software who wants to support wikidata statements and relations will have to go out of their way to implement that manually with or without json-ld in the mix, and interoperability between those software will have to specify how that works. and in your specification you can indeed make it so Simply Linking to the wikidata json-ld (which i don't believe it provides out of the box, it does for xml, turtle, and n-triples, if we're talking about rdf. if not, their bespoke json format is just as authoritative) can work (but i'd say using the Qxxx and Pxx IDs and letting the software figure out how to access it would be better!)

if you have the dream of making an as:Note and having it's as:attributedTo be the wikidata entity for alan turing... sorry, nobody other than maybe your own software will even attempt interpreting that

Sebastian Lasse

@sl007@digitalcourage.social replied · 33 minutes ago

@kopper

ah, no - that is a misunderstanding!

Anyone can feel free to represent the texts only and the user at least "knows" it.
But the thing for Public Broadcasters means 47mio. users in DE alone and given the unified codebase for the 5 projects _these_ softwares will interpret it.
It does JSON-LD you could just check by asking for any JSON-LD e.g. Q1055 (Hamburg) - it is content-negotiation.
The taxiteam software is funded by the German yellow cabs - the official ones (!) the codename is FCKUBR 😉 and I have no doubt about adoption fortunately.

Maybe we can work out better examples …

@hongminhee @julian

kopper :colon_three:

@kopper@not-brain.d.on-t.work replied · 33 minutes ago

@hongminhee@hollo.social @sl007@digitalcourage.social @julian@activitypub.space attempting to support this kind of "data contortion" (i made this up and prolly isnt the right way to describe this) would rapidly balloon the scope of every fedi software ever. i don't believe anyone would want to develop for such ecosystem

a similar example i saw was someone attempting to explain how you can partially inline an as:object you as:Like'd in order to specify you only liked that past version of it and if it changed your like shouldn't count. without describing this exact scenario i don't believe any software, json-ld capable or not, would interpret that Like as such. same thing with the long-form text FEP which attempts to support non-activitypub authors

Sebastian Lasse

@sl007@digitalcourage.social replied · 27 minutes ago

@kopper @hongminhee @julian

just btw, we had many W3C Social CG meetings about the importance and how to use the as:context property - not the JSON-LD @context and we all agreed.
About 30-40 devs attended.
Between 2016 and 2024 I attended basically any meeting. I felt that using wikidata urls in as:context was nice for anyone.

1 more replies (not shown)

Sebastian Lasse

@sl007@digitalcourage.social replied · 30 minutes ago

@kopper @hongminhee @julian

it is just damned simple, your as: Client can do so much by asking wikidata, OSM, federated geocoding and not our system. When you use a property for the first time, the client can cache its names in the languages of the user etc.

1+ more replies (not shown)

kopper :colon_three:

@kopper@not-brain.d.on-t.work replied · 4 hours ago

@hongminhee@hollo.social take this part with a grain of salt because my benchmarks for it are with dotNetRdf which is the slowest C# implementation i know of (hence my replacement library), but JSON-LD is slower than RSA validation, which is one of the pain points around authorized fetch scalability

https://wetdry.world/@kopper/114678924693500011

kopper :colon_three:

@kopper@not-brain.d.on-t.work replied · 4 hours ago

@hongminhee@hollo.social if i can give one piece of advice to devs who want to process JSON-LD: dont bother compacting. you already know the schema you output (or you're just passing through what the user gives and it doesn't matter to you), serialize directly to the compacted representation, and only run expansion on incoming data

expansion is the cheapest JSON-LD operation (since all other operations depend on it and run it internally anyhow), and this will get you all the compatibility benefits of JSON-LD with little downsides (beyond more annoying deserialization code, as you have to map the expanded representation to your internal structure which will likely be modeled after the compacted one)

Doug Webb

@douginamug@mastodon.xyz replied · 5 hours ago

@hongminhee I'm reading this thread as a relative noob, but what I see again and again: almost no one "properly" implents #ActivityPub largely because #JSONLD is hard but also because the spec itself is unclear. Most people who get stuff done have to go off-spec to actually ship.

This seems a fundamental weakness of the #fediverse - and that disregarding the limitations coming from base architecture. Seems to pose a mid/long-term existential threat.

What can we do to help improve things?

NextGraph

@nextgraph@fosstodon.org replied · 4 hours ago

@douginamug @hongminhee Hi Doug, I do have ideas to share about how to make schema on ActivtyPub more flexible and accessible to all social app makers.

Doug Webb

@douginamug@mastodon.xyz replied · 3 hours ago

@nextgraph very cool! Will have to look into your project more, I think I saw you talking as FOSDEM @hongminhee

🪨

@Varpie@peculiar.florist replied · 8 hours ago

@hongminhee@hollo.social I have the same feeling. The idea behind JSON-LD is nice, but it isn't widely available, so developing with it becomes a headache: do I want to create a JSON-LD processor, spending twice the time I wanted to, or do I just consider it as JSON for now and hope someone will make a JSON-LD processor soon? Often, the answer is the latter, because it's a big task that we're not looking for when creating fedi software.

Doug Webb

@douginamug@mastodon.xyz replied · 5 hours ago

@Varpie out of interest, did you look at Minhee's Fedify? It may be the JSON-LD processor you/people are looking for.

artemist

@artemist@social.mildlyfunctional.gay replied · 12 hours ago

@hongminhee I attempted to deal with parsing json-ld and I really wish they had just gone with XML. XML is also complicated, but it has mature implementations, while JSON-LD is a new protocol that never felt to me to have compelling advantages except matching data models people were used to using.

Jocelynephiliac :reclaimer:

@twipped@twipped.social replied · 13 hours ago

@hongminhee @jalefkowit JSON-LD is the sole reason I gave up on building anything for the fediverse. It is ludicrously over-engineered for the purpose, all the worst parts of XML crammed into JSON.

Want to add a field to any of the objects? Better be prepared to host a schema definition from now until the end of time. Good luck figuring out how to write that definition though.

Evan Prodromou

@evan@cosocial.ca replied · 13 hours ago

@hongminhee I agree that new developers should use a JSON-LD processor. It saves a lot of heartache.

Evan Prodromou

@evan@cosocial.ca replied · 14 hours ago

@hongminhee do you use the activitystrea.ms module from npm? It takes a lot of the pain out.

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · 12 hours ago

@evan I don't remember exactly, but I think I came across it while doing research before developing Fedify. I probably didn't use it because the TypeScript type definitions were missing. In the end, I ended up making something similar in Fedify anyway.

Evan Prodromou

@evan@cosocial.ca replied · 2 hours ago

@hongminhee that's great!

pettter

@pettter@social.accum.se replied · 20 hours ago

@hongminhee XML was always the better option tbh.

Luke Kanies

@lkanies@hachyderm.io replied · 21 hours ago

@hongminhee @jalefkowit huh. I’ve been pondering using it for some projects of mine, so this is good to know.

Is it a fundamental problem with JSON-LD, such that it should just be avoided, or a problem with how ActivityPub uses it?

And is there something else you’d recommend that fulfills the same goals?

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · 21 hours ago

@lkanies @jalefkowit To be honest, I'm not too sure myself. I just know that JSON-LD was originally planned as a foundation for the Semantic Web. I can only guess that if ontology is useful in a certain area, then JSON-LD would probably be useful there too.

Ben Pate 🤘🏻

@benpate@mastodon.social replied · 23 hours ago

@hongminhee

Great piece of writing, and I agree with lots of what you say here. Building this stuff is super hard, so good for you doing it “the right way.”

I hate not being able to trust the data I receive.

I’m one of those who’s taking the shortcuts, which has plenty of drawbacks, so I’m glad you’re in here fighting the good fight.

marius

@mariusor@metalhead.club replied · 22 hours ago

@benpate reminder that you can have a trusty library that fulfills more or less the same functionality of fedify any time you want to switch. ;;)

@hongminhee

julian

@julian@activitypub.space replied · 23 hours ago

⁂ Article

Re: I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

@hongminhee@hollo.social I'll give you my take on this... which is that my understanding of JSON-LD is that with JSON-LD you can have two disparate apps using the same property, like thread, and avoid namespace collision because one is actually https://example.org/ns/thread and the other's really https://foobar.com/ns/thread.

Great.

I posit that this is a premature optimization, and one that fails because of inadequate adoption. There are likely documented cases of implementations using the same property, and those concern the actual ActivityStreams vocabulary, and the solution to that is to communicate and work together so that you don't step on each others' toes.

I personally feel that it is a technical solution to a problem that can be completely handled by simply talking to one another... but we're coders, we're famously anti-social yes? mmmmm...

Sebastian Lasse

@sl007@digitalcourage.social replied · 3 hours ago

@julian

Manu, maker of JSON-LD who also helped with the AP Confs, made this nice video https://www.youtube.com/watch?v=vioCbTo3C-4

JSON-LD is a normative reference to ActivityPub. The context of AP is only 1 line, maybe 4 if you support the official extensions. It does not make anything much larger.

It is for example important if you want to consume the federated wikipedia, wikidata, European Broadcasting Union or these Public Broadcasters https://www.publicmediaalliance.org/public-broadcasters-create-public-spaces-incubator/ but also to know that e.g. mobilizon uses schema.org for addresses.

I give you an example, if you include
"mz": "https://joinmobilizon.org/ns#", "wd": "https://www.wikidata.org/wiki/Special:EntityData/",
"wdt": "https://www.wikidata.org/prop/direct/"

in your context, then you know about mobilizon extension but also the whole common knowledge of the world …
I like that, now you can support the whole vocabulary of wikipedia and wikidata which is just JSON-LD.
You get it in all the languages of the world including the properties name.
No problem, if others don't support it, but sad for users.

@hongminhee

Entity Data - Wikidata

Public Media Alliance

Public broadcasters create "Public Spaces Incubator" - Public Media Alliance

Four public broadcasters are partnering to develop solutions to address increasingly toxic, polarized and unsafe online discourse.

Sebastian Lasse

@sl007@digitalcourage.social replied · 3 hours ago

@julian @hongminhee

PS, I am using the official JSON-LD processor of Manu and contributors, if support in any language is lacking, we just speak to the JSON-LD Group (glad about the 2 webintents coming together now as well ) …
Cause we are social …

Doug Webb

@douginamug@mastodon.xyz replied · 5 hours ago

@pintoch read this thread?

Antonin Delpeuch

@pintoch@mamot.fr replied · 5 hours ago

@douginamug I saw it pass by, but I'm lucky enough not to have had to deal with JSON-LD too much so I don't have informed opinions to share 😊 In the group steering the reconciliation API, people have been discussing whether that API should use JSON-LD. I still don't understand what sort of interoperability would be expected from it. https://github.com/reconciliation-api/specs/issues/183

Matthew Exon

@mat@friendica.exon.name replied · 22 hours ago

@hongminhee @julian I'm a true believer in RDF from back in the day, so I'm hardly neutral. But...

There are essentially no interesting ActivityPub extensions right now. Even Evan's chess example, no-one's actually using AP to play chess. It's just ActivityStreams + a few cute tricks now and then. Even if there were extensions, existing AP servers chop off and throw away data they don't understand. so none of these extensions could work.

I feel like most of the "WTF am I learning JSON-LD for" criticisms are coming from this status quo. That includes "if someone wants to add a gallery thing or whatever, can't they make a FEP?" The way things work now, your extension either a) works only in your software or b) has to be painfully negotiated with the whole community. We're all gonna have a big fight about it on this forum anyway. Let's not pretend JSON-LD helps us.

But if we add two things to the mix, the situation looks different. Those are 1. server software that "keeps all the bits", and 2. a whitelabel extensible app. That would make it very easy to spin up crazy new experiences for a sizeable existing userbase. Developers should not be forced to endure a FEP process, and they should not have to attract a userbase from nothing. They should be able to just build, without even worrying if they're stepping on toes. And of course, Fedify and libraries in other languages are a load-bearing part of that world, including enforcement of the JSON-LD rules.

That world does not exist at all today, but JSON-LD does, so it's pretty valid to describe this design as premature optimisation. I dunno though, we don't seem that far away.

julian

@julian@activitypub.space replied · 22 hours ago

Re: I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

@mat@friendica.exon.name that's a really interesting point of view, and has some parallels to how app development on the ATProto side is easier in many ways.

I do think that this is something C2S (aka the ActivityPub API) can enable.

I am critical of JSON-LD but I do certainly recognize I could be very wrong 😁

Matthew Exon

@mat@friendica.exon.name replied · 22 hours ago

@julian I don't know as much as I'd like about AT Lexicons. That is, not so much how they work, but what the grand idea is? I don't even understand if Bluesky imagines them being mixed and matched JSON-LD style. I think not?

wakest ⁂ FOSDEM

@liaizon@social.wake.st replied · 4 hours ago

@mat @julian there are many atmosphere apps now that support a ton of totally different lexicons at once

Sebastian Lasse

@sl007@digitalcourage.social replied · 22 hours ago

@julian @mat

Do you know about the backgrounds of the immers project ?
, "no-one's actually using AP to play chess"
the reason that we have noa AP chess service _anymore_ is #uspol …

This all feels very unfair somehow cause I know the backgrounds but anyway …
While we 2 days ago had a long thread about our use of Chess Games I will link the video from the thread https://digitalcourage.social/@sl007/116023149133783002

immers with its federated locations and positional audio etc was supernice for playing chess !
Our use is fairly similar and straightforward like we did the chess Social CG meeting in 2018 and the rc3 (usually 18.000 people physically but here it was virtually cause pandemics) https://socialhub.activitypub.rocks/t/rc3-chaos-communication-congress/1202

Maybe it would really be fair if people are new to look into the 20 years Social CG history where some volunteers really gave much work :)
🧵 1/2

Sebastian Lasse

@sl007@digitalcourage.social replied · 21 hours ago

@julian @mat

We implemented this standard and you can create / describe your rooms [Place, `redaktor:fictional`] and the chessboard is just a geohash as described in the geosocial CG so the use is the same, just `redaktor:fictional` too,
You load the Collection of Chessfigures (pawn1 ...) can name them, they `Travel` over the chessboard ant the `Arrive` describes the `result`.
As always you can get very detailed with wikidata properties and entities but bare AS Vocabulary is enough.
In the end you have a Collection for the Travels which is your played game which you can replay or do whatever with.

But you can still install immers - it is worth a try https://github.com/immers-space

The reason for its end are the same as for the gup.pe groups and I hope people konw about it …

Matthew Exon

@mat@friendica.exon.name replied · 21 hours ago

@sl007 @julian I admit I didn't pay attention to immers at the time - I don't play games, not even chess. I was just using chess as an example, didn't mean to trigger anyone's trauma!

Still, it kinda proves my point. You have to use standard AS vocabulary because Mastodon, and if you squint then sure, Travel and Arrive, why not? But given some of the conversations I've seen on this forum, I shudder to think how that would go down if you tried to get approval for that usage from "the community" first.

2 more replies (not shown)

silverpill

@silverpill@mitra.social replied · 24 hours ago

@hongminhee

>There's no going back.

We absolutely must go back. Either we have a vibrant ecosystem where building stuff is a pleasant experience, or fediverse slowly dies while linked data cultists harass developers about nonresolvable URLs in @context.

JSON-LD adds nothing to ActivityPub, it only creates problems. Time to move on.

silverpill

@silverpill@mitra.social replied · 24 hours ago

@hongminhee

>There's no going back.

We absolutely must go back. Either we have a vibrant ecosystem where building stuff is a pleasant experience, or fediverse slowly dies while linked data cultists harass developers about nonresolvable URLs in @context.

JSON-LD adds nothing to ActivityPub, it only creates problems. Time to move on.

Lutin Discret

@lutindiscret@mastodon.libre-entreprise.com replied · 22 hours ago

@silverpill @hongminhee can someone explain what was it supposed to bring?

It sounds like people are attached to xml with schemas whike everyone is using schemaless json (xmpp vs matrix...).

Phantasm

@phnt@fluffytail.org replied · 21 hours ago

@lutindiscret @silverpill @hongminhee It was supposed to bring document schema validation (you shouldn't be able to fool a JSON-LD consumer into accepting invalid documents) and instead it added complexity that few know how to deal with and subtle vulnerabilities with plain JSON consumers due to the ability of overriding types.

Also it was supposed to be entirely optional, but the current spec editors would like you to believe otherwise.

silverpill

@silverpill@mitra.social replied · 21 hours ago

@phnt @hongminhee @lutindiscret

>Also it was supposed to be entirely optional

Yes, exactly, here's ActivityPub:

https://www.w3.org/TR/activitypub/#obj

Implementers SHOULD include the ActivityPub context in their object definitions.

Here's ActivityStreams:

https://www.w3.org/TR/activitystreams-core/#jsonld

Implementations producing Activity Streams 2.0 documents SHOULD include a @context property with a value that includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition using the URL " https://www.w3.org/ns/activitystreams".

In both cases it's a SHOULD, this means I am allowed to not include @context if I have a good reason to do so.

I have plenty of reasons but Mastodon can't process an activity if there is no @context. its_always_mastodon.jpg

Activity Streams 2.0

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

Fish of Rage

@sun@shitposter.world replied · 21 hours ago

@silverpill @phnt @hongminhee @lutindiscret I have wasted at least a full day on my latest AP project trying to get json-ld to work. again. I never learn.

Fish of Rage

@sun@shitposter.world replied · 21 hours ago

@silverpill @phnt @hongminhee @lutindiscret I have wasted at least a full day on my latest AP project trying to get json-ld to work. again. I never learn.

silverpill

@silverpill@mitra.social replied · 20 hours ago

@sun @phnt @hongminhee @lutindiscret JSON-LD: not even once

silverpill

@silverpill@mitra.social replied · 21 hours ago

@lutindiscret @hongminhee I have no idea, it is literally useless. JSON-LD is a form of gatekeeping.

arcanicanis

@arcanicanis@were.social replied · 21 hours ago

My first ActivityPub project was very literally just wasting my time solely on trying to make a JSON-LD-first ActivityPub library to try to abstract away it from the library consumer (within reason), back around the time before ActivityPub had reached W3C Recommedation status.

I would have saved myself some amount of months by just having not get snagged into that trap, and could have instead actually shipped a usable implementation back then.

Everyone else that actually shipped an ActivityPub implementation in the beginning were the ones that treated it solely as static JSON.

I'm not saying JSON-LD is hard, nor difficult to understand (and there are some niche projects where I do want to use it)---some of it's probably even an upgrade from similar things in the XML world, but it piles on more overhead that everything has to be expanded, checked against context, just to handle different representations, all while you'll still invariably have to interop with implementations that treat it as static JSON anyway.

arcanicanis

@arcanicanis@were.social replied · 21 hours ago

My first ActivityPub project was very literally just wasting my time solely on trying to make a JSON-LD-first ActivityPub library to try to abstract away it from the library consumer (within reason), back around the time before ActivityPub had reached W3C Recommedation status.

I would have saved myself some amount of months by just having not get snagged into that trap, and could have instead actually shipped a usable implementation back then.

Everyone else that actually shipped an ActivityPub implementation in the beginning were the ones that treated it solely as static JSON.

I'm not saying JSON-LD is hard, nor difficult to understand (and there are some niche projects where I do want to use it)---some of it's probably even an upgrade from similar things in the XML world, but it piles on more overhead that everything has to be expanded, checked against context, just to handle different representations, all while you'll still invariably have to interop with implementations that treat it as static JSON anyway.

silverpill

@silverpill@mitra.social replied · 21 hours ago

@arcanicanis @hongminhee @lutindiscret The trap is real, I barely avoided it myself. I read SocialHub a lot when I was learning about ActivityPub and got an impression that JSON-LD is super important so it was on my to-do list for a long time. Fortunately, I got distracted by other tasks.

silverpill

@silverpill@mitra.social replied · 21 hours ago

@arcanicanis @hongminhee @lutindiscret Linked data is good for scientific applications, but this is not what we're building here.

Lutin Discret

@lutindiscret@mastodon.libre-entreprise.com replied · 22 hours ago

@silverpill @hongminhee can someone explain what was it supposed to bring?

It sounds like people are attached to xml with schemas whike everyone is using schemaless json (xmpp vs matrix...).

marius

@mariusor@metalhead.club replied · 23 hours ago

> while linked data cultists harass developers about nonresolvable URLs

@silverpill I don't consider myself a cultist but I still think that putting invalid URLs in any payload where they are supposed to be meaningful is disrespectful towards anyone that consumes your API. Please don't do that.

@hongminhee

marius

@mariusor@metalhead.club replied · 23 hours ago

> while linked data cultists harass developers about nonresolvable URLs

@silverpill I don't consider myself a cultist but I still think that putting invalid URLs in any payload where they are supposed to be meaningful is disrespectful towards anyone that consumes your API. Please don't do that.

@hongminhee

silverpill

@silverpill@mitra.social replied · 21 hours ago

@mariusor @hongminhee The @context is not supposed to be required in the first place, but here we are adding it to every activity and wasting bandwidth because Mastodon developers didn't read the spec.

marius

@mariusor@metalhead.club replied · 9 hours ago

@silverpill I'm sorry, I'm not aware of that and I thought I read the specs pretty thoroughly. Could you point me in the right direction for where you got this information from?

@hongminhee

silverpill

@silverpill@mitra.social replied · 7 hours ago

@mariusor @hongminhee

@context is a recommendation, not a requirement.

ActivityPub:

https://www.w3.org/TR/activitypub/#obj

Implementers SHOULD include the ActivityPub context in their object definitions.

ActivityStreams:

https://www.w3.org/TR/activitystreams-core/#jsonld

Implementations producing Activity Streams 2.0 documents SHOULD include a @context property with a value that includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition using the URL " https://www.w3.org/ns/activitystreams".

Activity Streams 2.0

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

marius

@mariusor@metalhead.club replied · 6 hours ago

@silverpill aaah, I see. I think we've had this discussion before (or at least I had it with someone else).

For me "SHOULD" falls in the category of the robustness principle: "be conservative in what you do, be liberal in what you accept from others".

So for me if you treat "SHOULD" in a spec as non mandatory you haven't really implemented the spec.

@hongminhee

marius

@mariusor@metalhead.club replied · 6 hours ago

@silverpill aaah, I see. I think we've had this discussion before (or at least I had it with someone else).

For me "SHOULD" falls in the category of the robustness principle: "be conservative in what you do, be liberal in what you accept from others".

So for me if you treat "SHOULD" in a spec as non mandatory you haven't really implemented the spec.

@hongminhee

1+ more replies (not shown)

Aurochs

@aurochs@todon.eu replied · yesterday

@hongminhee Not into the void. I don't know shit about JSON or programming, but I did read your post! :-)

Rimu

@rimu@piefed.social replied · yesterday

JSON-LD is a trap. Sorry you fell in.

초무

@chomu.dev@bsky.brid.gy replied · yesterday

JSON-LD 를 제대로 다루는 라이브러리를 하나 만들어 보시면 어떨까요

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · yesterday

@chomu.dev JavaScript는 이미 JSON-LD 具顯(구현)이 있어서 Fedify는 안 그래도 그걸 가져다 쓰고 있어요 ㅋㅋㅋ

초무

@chomu.dev@bsky.brid.gy replied · yesterday

근데 왜 다른 사람들은 그걸 잘 안 쓰는 걸까요...?

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · yesterday

@chomu.dev JSON-LD를 그냥 JSON으로 다뤄도 괜찮다고 보는 사람이 많은 것 같아요.

Doug Webb

@douginamug@mastodon.xyz replied · yesterday

@hongminhee thank you for doing hard work with the plumbing! You are helping build coherence in this place and I'm grateful for it. Diverse people, unified standards 🖤

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social replied · yesterday

@douginamug Thank you so much for recognizing my hard work!