Inrupt has recently been talking about a “Data Wallet”, and for a while I thought it was just a new marketing term for a Solid POD, so I didn’t pay much attention. But a couple of days ago, they open sourced a native application to interact with this Data Wallet, and after further inspection I realized it’s not simply a Solid POD.
At first, I was confused because looking at the documentation, there are some endpoints to interact with the data like /wallet/{identifier}. And I didn’t understand what those endpoints were. In the blog post they say that the Data Wallet is built on top of a Solid POD (ESS), so in that case wouldn’t a client application use the normal Solid endpoints to interact with resources?
That’s how I found out that this “Data Wallet” is actually a new service, not just a rebranding of Solid PODs. It looks very similar to the Backend for Frontend architecture that we already discussed in this forum. But in this case, I think this really is a problem, because they are encouraging developers to build applications against this Data Wallet service (which uses the Solid POD under the hood, again as an implementation detail). To be clear, these Data Wallet applications will only work with Inrupt’s Data Wallet, they won’t work against any other Solid POD.
I always try to assume positive intent, and I really don’t like to criticize what other people or companies are doing publicly. But this time, I think it’s important to talk about it. I’ve shared my opinion of Inrupt in the past, and even though I didn’t agree completely with everything they did, I still believed they played an important role on pushing Solid forward. But this is different, if I’m understanding the situation correctly, this marks a transition from embracing the Solid Protocol to using a proprietary solution. I hope I’m wrong.
I read your post and went through the data wallet API and gave it some thought.
My two cents are who this is marketed towards. It says “industries and governments”, so this should not be labelled as a Solid-specific product, but a Solid-supported product.
I think some waiting will have to be done and observed. If it is a way to introduce more of industry partners to demonstrate that you can build services using Solid as a supporting protocol, it might support more industry acceptance and investment into the ecosystem.
On the other hand, if it is trying to walled-garden Solid (like how Google does with Android), then it is bad. It should also make it clear, like with their Notifications documents, that the Data Wallet only works against ESS, and applications built against it have no guarantee of success against other Solid server providers, and make encouragements to building towards the specifications BEFORE the usage of data wallet.
Today marks a significant milestone for developers and organizations looking to build safe and innovative digital wallets for their users. Inrupt is excited to unveil the developer preview of our open source Data Wallet, built on top of the robust foundation of the Inrupt Enterprise Solid Server (ESS) and leveraging the versatility of Solid Pods.
When it says “developers”, it doesn’t seem to imply “industry and government” developers.
That paragraph, in particular, shows why I think this is a problem. Just by reading this, you would think this Data Wallet is a Solid App. Only if you’re very familiar with Solid, and once you dig into the technical details, do you realize that this actually has nothing to do with Solid. Sure, it uses Solid under the hood, but this could as easily been implemented without a Solid POD at all. It is, again, used as an implementation detail. Which is pretty clear looking at the architecture diagram in their documentation. The Data Wallet app doesn’t even talk with the Solid POD.
To be clear, I’m not against Inrupt, or anyone, using anything other than Solid. The problem is rolling out your proprietary system, and making people think that they are building Solid Apps.
I apologize, I didn’t see that first link you referenced. I had read this one for the announcement, so I can see your concerns now.
Looking at the architecture, I do see your point. The introduction of the API wallet service between the Solid protocol and the Solid Pod is nice, but the API wallet service isn’t a Solid standard, and the backend could easily be abstracted away into MongoDB or something else.
At the same time, I can kind of understand why they might take this approach for instance because the semantic web has more mental overhead than the standard relational data model. I say this as someone with a casual interest in functional languages - OOP, RDBMS, SQL are all more intuitive than functional languages, semantic web, and related technologies. Especially since where I am (USA), there are not even university level courses for some of these topics rather than a passing mention.
I also see the reason for concern.
The problem indeed lies in the Data Wallet Service not being OS, nor open to other pod providers. That makes Solid, as you rightfully point out, an implementation detail.
To me the whole point of Solid is to offer a standard that decouples the storage from the app providers, and allows the user to freely choose their storage solution without the app provider having to know about it. A rule of thumb I regularly use to assess whether a solution fits the Solid mindset is : can I use a pod hosted in my basement, and still be part of the ecosystem without any disruption of service ?
Here the answer is clearly no.
If the Data Wallet Service API is meant to become a standard with an OS reference implementation, or at least can accomodate an arbitrary pod provider other than ESS, then it’s a welcome addition that bridges the gap between Solid and the solution providers that are scared away by the Solid technical aspects.
However I’m afraid there may be more of a business reason to this : the big dev budgets lie in the hands of actors that often cannot integrate into their business strategies the notion of not having control on the personal data store. It’s easier to make business if the entire chain of processing and storage is in contractual reach.
“Giving back control to the user” is too disruptive and makes business harder.
As someone who both a) spends a lot of their time working in corporate contexts and b) is a proponent of the overarching principles that Solid is/should be built upon, I do understand the argument in favor of the BFF pattern made in this page Backend-for-Frontend with Solid , which the Wallet service appears to implement. I have had to use the same pattern a few times and - gasp! - I’m happy to admit that in a couple of cases it even turned out to be the better approach in the long run.
There’s a tension between Solid and typical corporate requirements that requires compromises and tradeoffs, particularly when corporations are paying the bills. These compromises might not be the most palatable to everyone involved but, with some thought and coordinated effort, they can lead to positive outcomes in the long run. In my case, slowly phasing out the “middleman” BFF parts after a couple of years of building internal trust in the new systems.
I agree that the underlying ESS does feel like an implementation detail at this point… And that might be ok. Or it might not. When using the BFF pattern, the underlying solution is always an implementation details until it stops being so. What matters, IMHO, is whether there is a - honest - intention to “surface” Solid or standardize the Wallet API into Solid at some point in the future. However, depending on the specifics of current contracts, future plans might not be something that Inrupt is free to discuss in public and to this level of detail.
TL;DR - Is there a reason for concern? Yes. Is it the fact that ESS is - in the present moment - an implementation detail? No. The reason for concern is whether Solid will stand a chance at surfacing through the inevitable BFF pattern at some point in the long term. Ultimately, that’s up to both Inrupt and the community at large - compromise, iterate, deliver, repeat.
(Note that all of the above is strictly IMHO)
EDIT: elaborating on some super-quick feedback I’ve received, consider that Inrupt - as a company - doesn’t enjoy the luxury of time to the same degree that the community at large does. Note that I am not affiliated with Inrupt nor have I ever worked for them or with them and I am absolutely not speaking on their behalf but merely out of my own experience. I have run a small company in the past and I’m aware that pulling ahead can be, at times, a necessity. One that can be balanced out by reconciliation efforts at a later stage. This initiative might simply represent one of those “pulling ahead” moments.
Can you share some examples of what those “compromises and tradeoffs” are?
I already said this elsewhere, though I don’t remember where, but it seems to me that whenever that happens it means that the organizations are not really embracing the vision of Solid. In which case, I don’t know why they are using Solid to begin with (other than becuase it’s good marketing to say that you respect your users privacy, etc.).
As Philippe mentioned, the litmus test for whether an app is really a Solid App or not is whether it lets you choose the POD provider. That’s when you actually get all the benefits of Solid: privacy, data ownership, interoperability, etc. In any other situation, Solid is nothing more than a facade.
You mention that it can possibly serve as a middle step towards adopting Solid. Ok, if that happens then I’ll change my opinion. But we all know how those “temporary measures” often end up becoming the way things are forever.
Well, “the community at large” consists mostly of volunteers who are working on Solid in their free time. I don’t think there is anyone participating in the Solid community that is as well funded as Inrupt is. So if anything, it is the community that doesn’t have “the luxury of time”.
And to be honest, I still don’t understand how any of this is making things easier for Inrupt. Why not use ESS directly for the wallet backend, and add additional services for the functionality that is missing from the Solid spec? How is making an entire new endpoint that translates to Solid under the hood any easier?
Let me clarify my thoughts on this topic, first, as I think it provides some context on my general thinking on these issues.
Inrupt is a company, which - at the very least - has the critical obligation to pay its employees. Inrupt has also received funding and I’m sure that such funding has come with obligations to deliver something within a set of deadlines. I am not privy to Inrupt’s financials and therefore I don’t know whether they qualify as being well-funded but still, the fact remains that any funding eventually brings its own obligations. At least in my experience.
To this end, I must imagine Inrupt to be bound by expectations and obligations which, of course, do not apply to any of the volunteer work done by the community at large.
Earlier this year I resigned as chair of the WebID CG, A CG that was supposed to deliver on a very small subset of what Solid is and is based upon. The CG has recently been closed, having ultimately failed to converge and produce anything beyond CG report drafts in more than a decade of activity. Nothing in this is necessarily a bad thing (or a good one, for that matter) and I’m not casting any judgement. What I want to highlight, however, is the fact that volunteer work - precisely because it is unpaid and free from most obligations of paid work - can afford the luxury of debating and iterating on things for timeframes that would be wholly unsustainable within most business relationships.
This can be both a good thing, as it allows for more experimentation (see also academic research), and a bad thing, as it provides fewer incentives for participants to find compromises and solutions within actionable timeframes.
This is what I mean by “the luxury of time”. Companies do not enjoy that luxury to the degree that volunteer work does precisely because they need to meet the obligations that come with funding, revenues and, generally speaking, paying the bills and putting bread on the table.
In my opinion, Solid requires both commercial and volunteer effort and thus I’d be happy with having moments of greater tension between these two “sides” of its developer base, as long as they were to be followed by moments of reconciliation. I suspect - but I can’t be sure - that we might be in one such moment.
I can only speak based on my own experience but I know of no corporate context that would allow direct employee-to-POD data exchange, primarily as a consequence of data exfiltration concerns. I am also unaware of any corporate context which would be happy to have a direct dependency on something that’s not even remotely close to a standard yet. At minimum, I’d be asked to wrap access to PODs into an intermediary service under the corporation’s control - which is exactly what the BFF pattern leads to. Note that, as of today, these are cultural limitations before they are technical. Any proposal wouldn’t even reach tech people, it would be hard-stopped at the management level.
I suspect that for Inrupt to exist in a manner that is sustainable right now they’ll need compromises that might not be necessary were Solid more established already. They might also need a delivery cadence that the community at large might be unable to support due to the above, which justifies momentarily “pulling ahead” with such an API.
I agree and share your concern. At the same time, I can’t see how a company can exist today without these kinds of compromises.
Once again, I want to make it very clear that I literally do not know what I’m talking about, at least not with any kind of certainty. I don’t work for Inrupt and it’s probably a good idea for me to stop publicly wondering how they operate. I hope someone from Inrupt will join this conversation and give us their perspective. However, perhaps because of my experience with the WebID CG, I’m somewhat worried about the Solid community polarizing itself into the “volunteer” and “commercial” sides, progressively alienating one another until nothing remains in the middle. This is a small attempt at mitigating that risk by assuming good intentions and trying to put myself in someone else’s shoes.
Thanks Jacopo, I really appreciate your comments :).
I’m aware of that, but maybe that’s the problem. I certainly don’t want to get into philosophical discussions about capitalism and whatnot, so we can just agree to disagree here.
I’ll only say that I agree that companies have to be sustainable and make money, as I mentioned in a recent blog post. But I also think that it should happen whilst serving a mission, and I’m not sure that this Wallet thing is serving their mission (or at least what I think is their mission, by reading inrupt.com/about).
Now, if this is one step backward in order to make two steps forward, I’m fine with that. But so far, I’ve only seen the steps backwards from Inrupt’s latest decisions (or at least, the ones I’m aware of).
Who I was referring to in my previous message as “the community” was the people maintaining the various community artifacts: solidcommunity.net, solidproject.org, developer tools, etc.
+1
+1
Precisely, I would also like that. As I said in my initial message, I try to assume positive intent. But it is difficult if the main actor is missing from the conversation.
Jacopo, thanks for your great work in the WebID CG!
I wear a few hats and it’s difficult to separate the arguments and pick the right one, but since this conversation morphed from “I’m somewhat worried” to an invitation for “Inrupt to join this conversation” I will reply as an Inrupt employee.
And there isn’t much to say, Jacopo explained things very well. I would add the following:
Not only Inrupt open sourced the walled code (mobile apps for Android and iOS), but we are in the process of moving its governance to the OpenWallet Foundation. We hope OWF will accept it and, as you can see, everybody is invited to collaborate.
The Wallet uses a different API indeed, but data ends up in a Solid Pod, from where it can be shared with any Solid App. This is idiomatic for Solid and an good example of how a Solid app could/should be implemented. It’s just one that has wide applicability.
The API is public and documented, anybody can implement it any way they want, including using Mongo. Not what we would recommend, but possible. Yes, it’s not part of the Solid specs currently, but it may become a client-client protocol. Time will tell.
Related to 3. above, other Solid Server implementations may decide to support it. I am not sure about CSS, but I have high hopes for activitypods, which is currently the most actively developed open source Solid project. I encourage the community to engage and help with that project. I hope graphmetrix will consider that too, I don’t know how well it aligns with their business needs, but they also did some extremely interesting innovation around Solid. They are also bound by the economic constrains @jacoscaz very well pointed out, and I’d be more than happy to work with them on that if they see it as an opportunity.
Related to 3. and 4. above, adoption of the Wallet, and support for the API in other projects will, we anticipate and work hard towards it, lead to more Solid hosting providers, more Pods, more adoption, more interoperability.
I don’t think there’s anything that should give the community and @NoelDeMartin reasons for concern. Inrupt was very open and consistent in advancing Solid. The Web Linked Storage WG is currently formed to finalize the Solid specification after one year delay due, for the most part, to push back from a particular corner of the Solid community. We knew these are the realities of community work, we were determined to continue to push for Solid, and it happened. There will be more roadblocks down the road and Inrupt is determined to do everything in their power to continue to advance the idea of Solid and Web 3.0. TimBL’s and Inrupt’s message were always consistent.
So, if anything, I see reasons to be inspired by the new developments and continue to contribute. @NoelDeMartin, your Solid apps are some of the best, and you criticized the wallet API. I would highly encourage you to look in more detail at the API and make your critiques more concrete, bring them back here and improve the wallet API in the context of Solid, because that’s what we’re all trying to achieve.
The invitation to use and comment on the wallet API is actually not just for Noel, but everybody in the community. Much appreciated.
Does Inrupt plan to - at any point in the future - decouple the Wallet Service from ESS and make the former capable of working with any POD provider?
Would Inrupt support making the Wallet API a part of Solid’s standard protocol?
Just to be clear, I’m not arguing for or against any of the above. I’m just trying to understand how things are evolving. I do agree with @NoelDeMartin that for something to be backed by Solid storage should actually imply the ability to choose one’s own POD but, as I wrote in my previous posts, I fully understand that this might not be financially sustainable in the short term. Nonetheless, Inrupt is arguably the biggest name in Solid so it’d be good to know where the company stands. Obviously, I would also understand if you were not in a position to divulge this sort of information.
Assuming OWF accepts the projects, and I have high hopes, this will be an OWF project so, this question is for that community. The solid-data-wallet uses an API, which is not proprietary and documented, as such decoupled from ESS already. The only implementation of the API today is coupled to ESS, true, how that will change in the future depends again on the feedback. We are interested in feedback and we want to increase adoption, so what Inrupt will plan will be very dependent on that. Will Inrupt invest in implementing support for the wallet API in other Solid servers, unlikely, but we definitely encourage that and will do our best to help those who try.
Short answer, absolutely. The community will have to decide how, that wouldn’t be purerly an Inrupt effort, but yeah. The importance of client-client protocols for Solid was discussed many times.
I don’t see why you would agree that backed by Solid storage implies choosing one’s Pod. I agree that it would be ideal, it’s the implication I’m questioning. That makes Pods just general purpose storage, which is fine, but eliminates the class of use cases of specialized Pods and all the potential for innovation that goes with it. (I would guess that TrinPods are a good example). Such specialized Pods can be seen as Pods (as is the case for the Wallet), but the server may have additional logic to allow for specialized use cases. Nothing wrong with that in my view, so again, why is that implication there? Is there an assumption that Solid servers should have no additional logic?
That said, in this particular case it’s a moot point, because the API is public and others are encourage to implement and support it. Also, in this case there is no agenda, or secret to not divulge. Inrupt’s vision is the same, we continue to work towards growing awareness and adoption of Solid. Inrupt works with other organizations, from governments, to enterprises, to communities, like OWF in this case. Nothing new or interesting, really. All business as usual.
(Note: Inrupt called the repo inrupt-data-wallet for disambiguation. Inrupt didn’t want to claim that this is THE reference Solid wallet. OWF, ASF and pretty much all open source communities do not accept branded names, as they want to avoid the perception that they support/endorse a specific business. Hence the repository name change in the proposal to the more generic solid-data-wallet. Inrupt does not claim to speak for the community, and while I agree with the view that Inrupt is a very important member of the Solid community, we would like to see many successful businesses in the Solid space. I am clarifying this before other concerns are voiced).
Another important thing to note is that a new Solid service with high potential for adoption is a significant event in the Solid community. I applaud @NoelDeMartin for voicing his concerns and attempting this way to clarify the context. It is, to me, a sign of a healthy community, because it’s not always clear what’s going on. It can be clarified pretty quickly, however, if people communicate and establish a strong trust relationship. Never hesitate to voice your thoughts, and continue to do it an a positive way.
In my personal view, stating that X is backed by Solid implies that I should be able to use X with any implementation of the Solid “standard” - i.e. any compliant POD provider. I certainly have nothing against additional logic but I also would not identify anything strictly depending on such additional logic as backed by Solid. Not directly, at least.
From what I can understand, and I might be wrong, Solid aims to be a standard. Like MQTT, OCPP or, to stay within the HTTP realm, WebDAV and the recent JMAP. To offer a metaphor, if I had an MQTT broker offering a very specialized, non-standard set of features and a client that strictly depended on those features, I would not call such a client an MQTT client as it wouldn’t be able to operate with other standard-compliant MQTT brokers, defeating the entire point of adopting a standard.
That said… Solid is not an actual standard, yet, but merely a set of drafts, and I think Inrupt is best positioned to iterate (more) quickly and (more) efficiently upon variations until it eventually hits the right combination as determined by market interest and adoption. The result of this process will influence the LWS WG - as it should! - and the future Solid standard will be all the better for it. IMHO, Solid needs organizations with practical experience at scale in order to mature and I’m perfectly fine with these organizations having the power to push features almost unilaterally, such as what would likely happen if the Wallet API were to succeed (and I hope it will!).
However, given today’s drafts, I would still not identify the Wallet Service as backed by Solid. I personally feel it adds unnecessary confusion to an otherwise relatively clear picture. That said, I’m also very open to changing my mind. On any of the above.
Finally, thank you once again @hzbarcea for spending some of your time here. I really appreciate it and it did help clarify a few questions I had. I hope I did not come across as someone who merely wanted to split hairs. Having made my case and having received good feedback I’ll try not to intervene anymore; time stop occupying everyone’s precious mental space
I agree that if I can’t use it with my self-hosted pod, then it’s not consistent with Solid.
A wallet service seems generic enough that I could imagine it eventually being part of the standard, but I would not consider this a client-client protocol.
In my view, the whole point of a client-client protocol is that the server is generic enough to allow client innovation without needing to be customised. If one has to change the server API, then it’s not a client-client protocol. Up to now, that’s what Solid has been offering.
I agree with the assessment that the wallet service as currently implemented breaks with this. It says “The current Solid protocol is too hard for this use case, so we decided to implement a new API”. That’s disappointing, but also not surprising given everything is still in flux.
I’m personally happy with Solid as it is, and would be keen to see an explanation for why the wallet functionality couldn’t have been implemented without changing the server.
Thanks @hzbarcea for joining the discussion and sharing Inrupt’s point of view.
I completely disagree with that. According to that definition, any app in existence could be a Solid App without changing a single line of code. You just change the server to use a Solid POD in the backend and you’re done.
But of course, that’s not the point of Solid. On the contrary, the point of Solid is that data is decoupled from applications. For an app to really be called a Solid App, I should be able to continue using it with a different data source (meaning, a Solid Pod of my choosing).
Thanks for the compliments, I appreciate it :). But I think that proves my point. Any of my apps today work with ESS, but none of them work with the Wallet Service.
If you want concrete critique, I’ve already addressed my main concern. I understand adding functionality that is missing from Solid, such as the /accessprompts or /accessgrants endpoints. But I don’t understand the /wallet endpoint, because as far as I can tell, it doesn’t add any functionality that doesn’t already exist in the Solid spec. If anything, it’s worse because it doesn’t seem like you can do PATCH updates with application/sparql.
Indeed, Trinpod is a perfect example. They add additional functionality such as the /search endpoint; whilst conforming to the Solid spec. The proof is that all my apps work against a Trinpod Pod.
That’s my main concern here. It may seem clear from the name of the repository, but everything else in the announcement blog post seems to imply that Wallet Apps are Solid Apps. And I wouldn’t want newcomers to start making Wallet Apps thinking that their apps will work against any Solid Pod.
Seeing your comments, I don’t think there is any ill intent behind this, thanks for clarifying. It just seems like we don’t agree on what’s the definition for a “Solid App”.
I find it concerning that the “delay in finalizing the Solid specification” is being attributed to “pushback from a particular corner of the Solid community.” This kind of vague accusation is unproductive, as it doesn’t foster transparency or collaboration
As a community, it’s important to raise and resolve issues openly rather than let them fester. If there are genuine concerns, let’s discuss them in the appropriate forums and work together to move things forward. Reminder that we have a Solid Code of Conduct that helps us guide our interactions.
Hadrian, who is representing Inrupt, has been co-chairing the CG for about a year. Despite this, I don’t recall any meaningful discussions or code, and I can’t find anything on public record about wallets, aside from the contributions of Henry Story. In fact, this is, to my knowledge, the first time Inrupt’s wallet is mentioned in a Solid community space.
I find it concerning that these efforts are being put forward as if they are representing the CG or the community about a particular solution (or at least not clearly separated), especially coming from one of the co-chairs of the CG. This might be indicative that there could be a conflict of interest.
Public communication of this topic could use improvement, considering the clear guidelines at solid/CONTRIBUTING.md at main · w3c-cg/solid · GitHub - this is so that it is crystal clear that this solution has been developed exclusively and independently at Inrupt, without any input from the CG, and certainly not representative in any way of the Solid CG or Solid community as a whole.
For what it’s worth, I would encourage adopting a more collaborative spirit by proposing actionable solutions rather than merely pointing out pain points, particularly given that today’s Solid is a set of non-binding drafts (AFAIU) and tomorrow’s Solid might look different, though hopefully maintaining the same underlying principles and spirit.
Personally, I consider Inrupt as a very important player in the Solid space and I hope to see the Wallet API / Service grow to the point that it will trickle down into tomorrow’s Solid via the LWS WG. For the time being, however, I would suggest maintaining a greater degree of separation between today’s Solid and tomorrow’s.
As a practical example: the statement “built on Inrupt’s Enterprise Solid Server Wallet Service and utilizing Solid Pods” as quoted from the data wallet documentation could be refactored into the shorter “built on Inrupt’s Enterprise Solid Server Wallet Service”. I think doing so would better mirror the fact that, as of today, the Wallet Service does not use Solid PODs as commonly intended but only PODs managed by a specific service provider. At the same time, the shortened version of the statement still conveys the fact that the Wallet API / Service are being developed within the greater Solid space.
Insofar as we can, let’s do our best to meet one another in the middle. As @hzbarcea pointed out, Inrupt is not the only company that is building additional logic into their POD services and using it as a distinguishing factor. I interpret this as an indicator that today’s Solid isn’t (yet) capable of supporting commercial endeavors built solely upon “pure” POD hosting. If true, that would - IMHO - be a pretty significant issue with Solid itself that the community should cohesively aim to fix.
I’d like to keep the conversation productive and focused on constructive takeaways.
Is anyone aware of how the Inrupt’s Data Wallet fits with other developments in the field? For example OIDC4VP which was also present during a recent W3C FedID WG meeting focused on adding the Digital Credential API to the FedID WG’s scope?
I’m mainly focusing on all the credentials/certificates. Throwing any arbitrary data blobs into a “wallet” seems to make it more of a generic bucket or a box.
My take:
keep the conversation productive and focused on constructive takeaways.