Noel De Martin @noeldemartin@noeldemartin.social

It's still a proof of concept, but let me know if you think this is cool or you have some questions :D.

I'm calling it "Vivant", and you can find this and other examples in this playground: https://noeldemartin.github.io/vivant/

Recently, I've been learning to make animations on the web. And I'm starting to understand why Framer Motion is one of the reasons for people to choose React over #Vue.

But I still want to use Vue! So I started working on a library that supports layout animations, like this one:

@angelo Perfect timing for @dbat!

Just to make sure, I tried with the Community Solid Server as well, and it also works so I guess it really is something that will work with most Solid PODs :).

Though it seems to rely on the .html extension, so I'm not completely sure it's part of the spec. But it seems like it works in practice.

@dbat @csarven I understand the confusion, because Solid's vision is very broad and all encompasing. But if you actually understand how it works, it's not that complicated.

Still, I'm sure you will read many people talking about what it could do in the future. That's why I like to distinguish between what it can do today, and what it can potentially do in the future.

If you haven't seen it, I gave a talk where I explain the basics in ~10 minutes: https://noeldemartin.com/fosdem

@dbat @csarven Well, yes and no.

Technically, Solid PODs store 2 types of documents: RDF Resources and non-RDF resources (also called "binaries"). Ideally, most things you store would be RDF resources, because they are the ones that contain semantic data that any application can understand. But you can also have non-RDF resources like images, videos, ... or HTML files.

However, I don't think the spec mandates that when you visit the url for a non-RDF resource, it should return its contents.

@dbat Maybe @csarven can answer why the part on "how to write" is not explained :).

Personally I haven't used dokieli because I use Laravel for my actual blog. But if I wanted write plain HTML files I'd probably just use Github Pages because it seems a lot more straightforward than using a Solid POD. I think Solid can be great for interoperability, but for read-only documents (like a blog), it can be overkill. Maybe you could have a comments section with Solid though.

@dbat You can write html files and solidcommunity.net will render them if you visit the url. And you can use something like https://dokie.li to write the files. For example, like this: https://solidos.solidcommunity.net/

But I don't think that's something all POD providers will do, it may be specific to solidcommunity.net.

If you're interested to learn about the practical uses of Solid, I'd suggest looking at @angelo's video series on Practical Solid: https://forum.solidproject.org/t/practical-solid-video-series/7974

@dbat Unfortunately, that's one of the things I address in the article; there isn't any good POD provider I can recommend :(.

But things being what they are, the best recommendation I have is solidcommunity.net for an online account, and the Community Solid Server to play with Solid locally: https://github.com/CommunitySolidServer/CommunitySolidServer

The good news is that if an app is made properly, there shouldn't be any difference between an online account or localhost. I myself use a local POD when I'm just testing apps.

@ylebre @dbat Hey, thanks for recommending my apps :D.

I see how Solid can be confusing at first, I recently wrote a blog post answering exactly this question "Why would anyone use Solid?": https://noeldemartin.com/blog/why-solid

Though maybe it's easier to see it in practice... You can use one of my apps (for example, this recipe manager), and the point of Solid is that you or anyone else could also make an app using recipes that works with the same data. No need to choose only one: https://umai.noeldemartin.com/

@VincentTunru @jg10 @angelo They don't even mention Solid in this article, and I think that European eID has nothing to do with it either.

Which is fine, but for me the problem here is that, again, they are conflating this with Solid. It's fine if Inrupt, Europe, or whoever doesn't want to use Solid and they roll out their own spec/technology. But don't make people think that this has anything to do with Solid or what Tim is trying to do.

@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.