@mfru at the intersection of Solid and Activitypub there is @activitypods that is BTW pivoting to @nextgraph as we think the truly decentralized POD based on RDF is in fact NextGraph. Of course we are biased, but maybe we are onto something

@mfru@mastodon.social I worked on Solid at Inrupt on the javascript sdk team, and the biggest problem solid has is learning curve, which is why I've been saying "AT Protocol is a bunch of the solid ideas but waaaay simpler learning curve" partly because you don't need to mess with json-ld

That and not even Inrupt appear to publicly do Solid anymore, they're all wallets now, apparently?

@thisismissem @mfru

In your opinion, did you feel that the complexity of Solid was ONLY due to JSON-LD?

Or, were there other (non- JSON-LD) things that made it complex, too?

There were a few other things (conflicting standards such as ACP vs WAC), but the JSON-LD was repeatedly the thing that developers found hard to wrap their head around. "How do I create a schema?" is a pretty normal question for an application developer, when you're used to working with traditional web app stacks. "Oh, it's JSON" and then they learn, nope, it's not: every property is optional, every property is one value or an array of values. The JSON-LD learning curve is so high that even people I think know it, generally go "yeah, nah, I still don't fully get it"

So to develop an application with JSON-LD you basically need to deal with garbage in hopefully data out. It's not familiar nor simple to 99% of web developers. It's an incredibly niche community of people who actually get it, and they tend to work at companies who really benefit from the properties of JSON-LD.

@nextgraph @activitypods ActivityPods / Nextgraph looks extremely interesting!

@stuartyeates @mfru I think a critical mass of apps for a smaller number of users would also be ok - data sovereignty advantages can be obtained without network effects. There's still enough dev activity that the jury is out on whether this will be achieved.
#SolidProject

@reiver @thisismissem @mfru

I made a diagram yesterday that contrasts #ActivityPub and #SolidProject that is I think interesting to consider.

In the past I've been very active on the Solid forum, and tried to get a collab going with #SocialHub community. A number of points that existed then, are still issues today I think.

Like, though anyone could participate in the standards process via chat, the Solid team and Inrupt were not really interested in their community, hardly giving attention while people were building interesting stuff there.

Also at the time basically all available code was Javascript, making Solid uninteresting or hard to access for other language devs.

But I think biggest issue was that Solid didn't know what it was. It was positioned as 'personal data vault' on the landing page then (but not using this term), but was 'secretly' TBL's desire to reboot the #SemanticWeb. The new web would be all 'Solid apps'. But the adoption strategy for that didn't exist.

@reiver @thisismissem @mfru

Here's the diagram btw: https://social.coop/@smallcircles/116113963712755122

The problem of #SolidProject knowing what it is, is more an inherited problem of #LinkedData / #SemanticWeb knowing what it is.

Semantic web always was "if only all information on the web were semantic and machine-readable, then...". And there it stopped. Presumably magic would happen.

And perhaps it would. But to make such a big leap, a paradigm shift of the entire web, along the way you have inspire a whole lot of people to set the (r)evolution in motion and keep it going.

If you look at what linked data is, it is a very low-level format. Nice if you have it, but now what are you going to build with it? There are some good application areas, but the case for linked data elsewhere is not a given.

Still today there are regular discussions on 'what would be the killer app for Solid' or linked data in general. Saw some interest for LLM's fed semantic data to make them more deterministic. I'm not interested.

@mfru @nextgraph @activitypods that sounds super interesting indeed, would love to know more!

@reiver @thisismissem @mfru

The chicken/egg of getting good tool support for Linked Data et al remains a serious issue.

The standards are complex and intertwined with each other in intricate ways. Regular devs need to be shielded from that, and have tools that allow them to focus on solving problems, building solutions, satisfying needs.

Without the tools, barrier to entry is real high. But because of that there are also less folks who build and improve tools.

Last problem that is important to mention, is more a social issue. The generalized "dev community" has made up their mind that they dislike linked data, just as they did before on XML, for instance. It is a particular mindset that has taken hold, caused by the first hype cycle around Semantic web, where it didn't deliver.

I'd advise anyone in LD space to incrementally prove value solution-side, and not emphasize too much on linked data as unique selling point. Alongside strengthen the ecosystem to get better tool support.

Hi @thisismissem,
yes, IMHO the question is, how big should the mental burden be implementing simple things?
Does AP want to be basic infrastructure, then it should strive to be basic.
I liked the line of thought of @mariusor in a chat with @steve on C2S complexity on C and S sides (keeping servers basic and let lients elaborate). Can't find the post right now.

> @smallcircles@social.coop said:
>
> the Solid team and Inrupt were not really interested in their community, hardly giving attention while people were building interesting stuff there.

Yeah, the Inrupt leader ship were all not startup people. They didn't get devrel or really startups. There were more managers at Inrupt when I left than people actually doing the work when I left. (at least, that's how it felt). I think after I left like 2-3 other people also had enough and left.

@mro@digitalcourage.social yeah, for protocols to succeed they need to know when to be complicated and when to get out of developers way. There's some complexity that you can do on the server side, but the client needs to be why you solve that complexity. A server can easily do things like filtering over a dataset. For a client that can be really expensive, since it means retrieving a bunch of data you don't need.

@thisismissem just stumbled over your comment here.

Why did the developers need to come up with a "schema" in the first place? Proper data modeling is hard (as you say too)

Devs can just define their JSON objects and store them on a Pod, and read them from the Pod in their app. You _can_ simply ignore the LD part here. (My students always do that first when they are already used to web dev)

Doing data modeling for LD (which we should! ) just gives you more features from the RDF world, no?

@uvdsl@w3c.social because you usually need to have some understanding of the data you work with.. database schemas exist because we like structure to things. Dealing with "any" data doesn't really allow you to build an application. It's kinda like how MongoDB's big feature was "no schema! no migrations" and sure enough people who bought into that have realised that this actually meant "all the migrations are in every single code path that you need to access data to interact with it", which ends up being costly in tech debt.

Schema simplifies things by giving you a known shape of data to work with.

@thisismissem Ah, you are assuming that the dev is also doing the data modeling. Gotcha, makes sense for Indie-Devs or small ventures.

Still, what you describe is not particular to JSON-LD. Devs can simply store their JSON objects in a Pod.

In my experience, the "confused dev" that you described above occurs when the devs are forced to use JSON-LD without understanding the basics of RDF. Proper on onboarding is crucial here, tooling like LDO and similar do exist to ease LD development ...

I mean, yeah, of course you can store arbitrary blobs in a pod, but all the tooling tries to incentivise you to use json-ld / rdf.