Noel De Martin @noeldemartin@noeldemartin.social

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.

I've been working on #Solid for more than 5 years, and sometimes people ask me why. If you've also wondered that, here's my answer: https://noeldemartin.com/blog/why-solid

I always talk about Ramen, but up until recently I hadn't cooked it myself. Some months ago, I finally did it and I'm quite happy with the results :D.

Of course, I've still got a lot to improve, but it came out pretty decent 🙈.

https://umai.noeldemartin.com/viewer?url=https://noeldemartin.solidcommunity.net/cookbook/ramen

@VincentTunru @marleenstikker Nice write-up :D. I've actually met part of the ActivityPod's team: @srosset and @laurin. And I really like the idea of mixing both Solid and ActivityPub. I'm sure something great will come out of all this work :).

The only comment I have about the article, though, is that Umai is not a "demo" app! Or at least that's not my intention 😂. But I see how someone could get that impression in it's current form. So no problem with the misunderstanding :).

@VincentTunru @marleenstikker Cool, thanks for the heads up :D I'll check that out :)

Here's the recording of my second talk at the Symposium.

I found about CRDTs and local-first some years ago, and they fit perfectly with the way I wanted to build apps. In this presentation, I share how I applied them to Solid. Check it out! #sosy2024

https://youtu.be/vYQmGeaQt8E

In case you missed last week's Symposium, here's my first talk!

It is about Developer Experience, a topic dear to my heart. I talk about the tools I've created and what's important for Solid DX overall. Let me know what you think! #sosy24

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

This slide from the SolidLab session says a lot about the Solid Ecosystem and what I struggle with the most as an app developer #sosy24

"use your privilege for common good" Love this closing line from @csarven's presentation! It's great to finally see him live :) #sosy24

If you're interested in the full recount of my experience going through the course, you can read it in my website: https://noeldemartin.com/tasks/learning-css