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
@noeldemartin This is a very worrying development, inrupt never really participated in the Solid community which is bad enough and now they seem to actively working against everything we are doing.
@noeldemartin the wallet app is not a #Solid app. It is an Inrupt PodSpaces app that you can only use with an Inrupt PodSpaces Account. It's a classic proprietary app coupled to a proprietary backend. Nothing about this is Solid.
PS: phone autocorrected Inrupt to Insult, which might be a sign
@angelo @noeldemartin It is open source at least, so there's that: https://github.com/inrupt/inrupt-data-wallet
Looks to be a fairly basic API. I wouldn't necessarily say that it's working *against* Solid, as much as that it looks like it doesn't have much to do with Solid. Just yet another enterprise service.
As for what Tim thinks: https://www.inrupt.com/solutions/data-wallet
> Data Wallets will drive a user-centric Web 3.0.
(No mentions of Solid. So maybe a pivot away from Solid?)
@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.
@noeldemartin @VincentTunru @angelo
It actually looks like the main non-standard endpoints relate to access requests and grants, and the interaction with wallet objects is still Solid.
My understanding is that the spec might still end up going this direction?
I'm not keen on backend for frontend either though.
@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/
@noeldemartin @VincentTunru @angelo
Maybe I'm naive, but what I see is a presumably RDF-less container listing+GET/PUT/DELETE, which seems like yet another attempt at encapsulating the "hard bit".
If one day the spec has access grant requests and ESS is spec-compliant, then other apps would be able to talk directly to the wallet's data.
On the other hand, I consider this particular access grant API rather complex, and would hope that it gets encapsulated a bit more if it gets to the spec.
I'll offer this article that Inrupt linked to in their latest newsletter. Apparently already published at the start of this month. Lots of it is vague and hand-wavy, so I'm not sure what to think yet, although the future sketched by the author in the intro sounds fairly dystopian: https://thenextweb.com/news/eu-digital-id-supports-universal-digital-wallet
@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.
@noeldemartin @VincentTunru 💯