Noel De Martin @noeldemartin@noeldemartin.social

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

I've been working on a redesign of my first #Solid app, a Task Manager called "Solid Focus". It's looking pretty nice, I can't wait to release it :D.

@VincentTunru @johnonolan Thanks for the shoutout Vincent :D.

Yeah, I don't do a lot of server-side these days, but I still love Laravel and if I have to do something server-side, it'll be Laravel :D.

@ylebre @dougholton I'm aware that choosing a vocab is one of the biggest roadblocks for beginners, but recently I've started thinking that it's not as important as I thought. I think when in doubt, you should just choose one that "looks right", or make your own if it doesn't exist, and move on.

Eventually, we should have a way to make apps interoperable with different vocabs, otherwise it's not realistic to think that developers will just choose "the right vocab" every time.

@ylebre @dougholton If the tutorial is for beginners, I'd just choose a vocab and use the same one for everything. We used schema:Action for the Hello World examples simply because schema.org is the most popular ontology and has nice documentation. I'm using it for my app as well for the same reasons, but as I said it's not final.

By the way, check this out if you haven't seen it: https://www.w3.org/DesignIssues/BagOfChips.html

@dougholton @ylebre Hey, thanks for the ping.

I initially used purl lifecycle, but I'm not super happy with that. I started rebuilding the app, and now I'm using schema:Action + a custom vocab for advanced features, although that still isn't final.

I also have to think how to tackle migrating data for existing users, but it seems like there isn't a no-brainer vocab for making TODO lists with Solid. So yes, these apps will probably need the ability to translate between schemas at some point.

@VincentTunru Interesting, I thought of it as:

- Approve: Ready to merge.
- Comment: Ready to merge, but I've got some optional feedback or suggestions for improvements.
- Request changes: Not ready to merge.

Also, it's always frustrating when I have different required/optional feedback; but can only have one review status :/. It'd be nice to have it by individual comments.