Noel De Martin @noeldemartin@noeldemartin.social

@jg10 @VincentTunru @angelo That's not entirely true. What I find most worrying is the /wallet endpoint, which is intended to perform CRUD operations on the resources. If you look at the documentation, it has nothing to do with the Solid spec.

This diagram in their documentation makes it pretty clear. They want Data Wallet apps to talk directly with this Data Wallet service, which internally will communicate with the Solid POD in the backend: https://docs.inrupt.com/data-wallet/patterns-and-flows/

@VincentTunru @angelo The issue is that the open source repository is just the app, the server is still proprietary.

I think this goes against Solid because one thing is making an app that only works with your server (e.g. the BBC app), another thing is to actively encourage developers to make those kind of apps.

What's worse, unless you're very familiar with Solid, you won't even realize you're not making a Solid App because the way they talk about the Data Wallet and Solid is very confusing.

Inrupt recently open-sourced a Data Wallet, and I have some comments about it. If you care about #Solid, I think it's important that you're aware of what's going on. Join the discussion in the forum: https://forum.solidproject.org/t/inrupts-data-wallet/7836

@pietercolpaert @rubenverborgh @besteves4 Also, I think you may already be aware of my library; but since it's not referenced in the paper I'll mention it. I'm using a library (that I made) called Soukai which already does what you mention in the paper, parsing RDF as JS Objects (using the Active Record design pattern). I'm not using any RDF shapes to define the mapping or anything, but I think it'd be pretty easy to implement that :). https://github.com/noeldemartin/soukai-solid

@pietercolpaert @rubenverborgh @besteves4 Hey! I just read the paper on RDF lenses, and my interpretation of "RDF Lenses" was different. Rather than transforming RDF into JavaScript; I was thinking that it would handle translating RDF between vocabularies. I guess in RDF parlance that's referred to as "reasoning" or something? I got that idea of lenses reading about project Cambria here: https://www.inkandswitch.com/cambria/

@vorburger @VincentTunru Hey, thanks! :D I'm glad you like it, and hopefully we'll keep making it better :)

Somewhat reluctantly, I'm going to start using Bluesky 😅. Twitter is getting worse by the day (almost nobody sees my Tweets anymore), and I've had this Mastodon account for ages, but it's too technical for some people. So I'll be using 3 apps that do basically the same thing 🤷.

In any case, as you may already know, I'm not super active. I'll continue cross-posting everywhere, but the best place to follow my work is still my website, which you can subscribe through RSS: https://noeldemartin.com/now

@jg10 The good thing though, is that since my apps are local-first that shouldn't be too much of a problem. But I'm aware it could be an issue as a general-purpose POD replacement.

However, I think it's a worthy trade off for people who are getting started with Solid. If they know nothing about Solid but have a Nextcloud/Dropbox/Google Drive/etc account they can get started with something like this and eventually migrate to a "real POD" when they need it.

@jg10 I haven't tested with a lot of data, but with a couple of free Nextcloud providers I saw a noticeable difference :/. One of them was fine, I wouldn't be able to tell that it wasn't a "real POD". But another one was painfully slow, so I guess it depends on the Nextcloud server.

@VincentTunru I was going to say that it doesn't work, but actually it does :D. I'm sure there are some things that are broken, but I could see my files and edit some triples :).

This was a far fetched idea, but seeing how easy it's been, I may consider making it for real. I know the devil is in the details, but so far I've been pleasantly surprised. I also have to give credit to Laravel, which makes this type of quick prototyping a breeze.

Last week I started tinkering with this Solid Server from scratch, and now it works with most of my apps (including authentication!). Furthermore, it uses a Nextcloud account for storage :D.

It's just a proof of concept; and I didn't implement any of the hairy stuff (authentication, authorization, content negotiation, etc). But with very little effort, it works with a couple of my apps. So it already covers 90% of the functionality I rely on as an app developer.

It's because of things like this that I always say that in reality, Solid is very easy to learn. If you grasp the basics, it's really not a lot more complicated than understanding REST apis.

During my sabbatical, I've decided to try making a Solid Server from scratch to see how complicated it would be... And turns out I got it working in a single day 🤯.

It's very experimental, but check it out if you're curious: https://github.com/NoelDeMartin/lss

#Solid #SolidProject

The times they are a-changin'! After almost 5 years at Moodle, I've decided to quit my job and take a sabbatical. I'll be back to work in January 2025, so I'll have plenty of time to ponder what to do next.

You can learn more about it in my blog: https://noeldemartin.com/blog/the-end-of-the-chapter

This weekend I rebuilt my Freedom Calculator mini-app. I built the first version years ago when I started thinking of quitting my job, to see how long I could remain unemployed working on personal projects. It'll come in handy soon :). https://freedom-calculator.noeldemartin.com/

@santisbon But the second, more important one, is that permissions are defined at a document-level, not on triples. And you need to make sure that the SPARQL endpoint respects those permissions. So that could be challenging to implement properly.

There has been this discussion about the document model vs the graph model, but for now it's all in theory. The current spec is using a document model. If you're interested, you can learn more about it in this blog post: https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/

@santisbon In a nutshell yes, but there are two things to keep in mind with that approach.

The first one is that even if you do that, the SPARQL endpoint is not part of the spec. So applications that want to work against any spec-compliant POD couldn't take advantage of that feature. They could use it and fall back to the spec-compliant rest API if the SPARQL endpoint is not available, though.

@santisbon The way data is stored is an implementation detail, different POD providers do it differently. The only requirements that the protocol mandates is that you can write RDF triples to documents, or store binary files. I gave a presentation introducing how Solid works, in case you're interested: https://www.youtube.com/watch?v=kPzhykRVDuI

New video is up! This time I talk about routing and how I've been working on the new UI.

https://www.youtube.com/watch?v=pDK6oQ6igLg