Discussion
Loading...

Post

Log in
  • About
  • Code of conduct
  • Privacy
  • About Bonfire
julian
julian
@julian@activitypub.space  ·  activity timestamp 5 days 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...

  • Copy link
  • Flag this article
  • Block
Doug Webb FOSDEM
Doug Webb FOSDEM
@douginamug@mastodon.xyz replied  ·  activity timestamp 4 days 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?

  • Copy link
  • Flag this comment
  • Block
julian
julian
@julian@activitypub.space replied  ·  activity timestamp 5 days 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...

  • Copy link
  • Flag this comment
  • Block
Matthew Exon
Matthew Exon
@mat@friendica.exon.name replied  ·  activity timestamp 5 days 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.

  • Copy link
  • Flag this comment
  • Block
julian
julian
@julian@activitypub.space replied  ·  activity timestamp 5 days 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 😁

  • Copy link
  • Flag this comment
  • Block
Matthew Exon
Matthew Exon
@mat@friendica.exon.name replied  ·  activity timestamp 5 days 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?
  • Copy link
  • Flag this comment
  • Block
wakest ⁂
wakest ⁂
@liaizon@social.wake.st replied  ·  activity timestamp 4 days ago

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

  • Copy link
  • Flag this comment
  • Block

Bonfire social

This is a bonfire demo instance for testing purposes

bonfire.klasse-methode.it: About · Code of conduct · Privacy ·
Bonfire social · 1.0.1 no JS en
Automatic federation enabled
Log in
  • Explore
  • About
  • Code of Conduct