lots about data ownership and interoperability in my recent conversation with Jess Martin:
Even when you #OwnYourData 100%, many might find little agency in being able to ‘edit properties on JSON objects’. What level of handedness would be meaningful to them?
This was an awesome conversation! It touches many points I’m very passionate about. Specially, the importance of interoperability being the main differenciator to end-users for using Zero Data Apps.
Case in point, I have some questions for Jess but I don’t think he has an account in this forum. So I guess I’ll ping him in Twitter / X or something. But as an end-user, this sucks. I just want to talk with him, and each one should be able to use their own platform to reply without needing to create new accounts.
Furthermore, this has also been posted elsewhere (Twitter/Mastodon/Youtube). So now if I want to follow the conversation, I have to manually check all of these platforms . Situations like this are why I think interoperability is so important. Solving this is only possible with Zero Data Apps. But the sad thing is that until there are enough apps (using the same protocol) to make this possible, end users won’t even realize it. It’s a chicken-and-egg problem at a market level :/.
Anyhow, one of the things I wanted to ask Jess is how they think about interoperability at DXOS. Looking at their documentation, it seems like data is modeled using something called Protocol Buffers (first time I hear about them). Which look interesting, but it seems like for apps to be interoperable, they have to use the exact same schema, right?
It’s of course better than nothing, but in the long term I don’t think something like that would work to achieve the full vision of Zero Data Apps. I wrote this post a while ago called Interoperable Serendipity, and I think this would fall in the “Intentional interoperability” category.
Personally, the reason why I’m focusing my efforts on Solid rather than other Zero Data protocols is that I think it’s the closest to achieving my ideal of Interoperable Serendipity. Of course, we’re still very far from that, but I think the chances that two Solid developers use the same schema are a much higher than any other protocol, because there are already established vocabularies such as schema.org. RDF also has some built-in mechanisms for inference (called “reasoning”), although we are not taking advantage of them at this point.
Although to Jess’s credit, he does monetion that DXOS may not be the solution that ends up making it in the end, but it helps move the needle. I agree, and I’m also not convinced that Solid will be the one that eventually makes Zero Data apps go “mainstream”. Ultimately, my biggest worry about the Zero Data ecosystem is the following:
But maybe I’m only looking at this in the short-term, and all this ramification is necessary to solve many of the problems we still have. And eventually, once most important issues have been tackled, a new protocol will emerge that will finally make it a reality. We’ll see :). Until then, I’m very happy that this Zero Data movement is happening and it can empower some small communities and indie developers.
Yes, I think consuming or publishing cross-posts would actually be quite a compelling use case if there were a Zero Data option, as it would simplify a complexity that many people have daily, just would need the platforms to open up (which I guess they wouldn’t)… ActivityPub / ATProto might be a useful step, perhaps Ghost dipping into Webmentions another…
My view of interoperability has changed from ‘apps supporting the same protocol / format’ to ‘apps supporting a plurality of protocols / formats’, to the extent of even considering domain-specific integrations with existing platforms like Dropbox, Pocket, Ghost, Wordpress that, although are not exactly Zero Data, are open enough to enable data to flow and be integrated in interesting ways.
I’m also quite convinced by Gordon Brander’s concept of simple seeds that interoperability comes through accepting ‘messy formats’ and not by defining specs.
Yeah, email is great because everyone already has an account. But the UX is not great.
For example, I do like that this conversation is happening in public and other people can read it and participate. I guess you can do that with mailing lists like the one we have for Solid, but it’s not something that comes out of the box with email.
Also, the UX of writing, quoting, etc. is not great. I really like Discourse (the platform that powers this forum), so I’d love to have this UX for all my public, forum-like conversations.
I think ActivityPub is a good step towards achieving this vision, but it seems like it’s more focused on short-form content. Maybe something like Lemmy could work for the use-case I’m talking about. But then, we have a protocol per use-case:
Ideally, all of them would use the same thing. In the same way that you can use PHP, Ruby, React, Vue, or whatever framework you like, but in the end you’re making websites with HTML, CSS, and JavaScript.
This solves the problem for one particular app. If you’re capatable of adding integrations for remoteStorage, Fission, and Dropbox then most of your users will be able to use your app. But then, when they try to move to a different app, they’ll have the same problem.
I think the ideals of Zero Data are great, but in practice for most people having access to their data is meaningless if they can’t use it anywhere else.
There’s been this discussion in the Solid community for a while about which will be the “killer app” that everyone starts using and makes Solid go mainstream. The same could be asked of Zero Data in general. My opinion has changed over the years, and now I’m convinced there will be no killer app. Instead, if this is going to succeed, it will be because there will be an ecosystem of apps that work together. And I think it would be awesome if that ecosystem is built by indie developers. But I can’t see that happening without Interoperable Serendipity.
Maybe something like Cambria or some AI tool can finally make it possible, but I think we’re still very far from that.
Yeah, the story of my life is trying to make things super simple and ending up with complex monstrosities xD.
But at the same time, I don’t see how accepting messy formats can be made simple :/. I would love to see that working in practice.
Just a random thought, but having our very own pocket AI (LLMs) programs that can analyze messy formatted data and quickly write code behind the scenes to extract information from them might be how this gets solved.
So glad you brought all of this up. “Interoperability serendipity”, as you define it, is one of goals I’ve been working towards for several years. It’s really high bar! We’ll have to make incremental steps to get there.
With DXOS, we’re trying to ship a production system that enables developers to build interoperable apps today, so we’re trying to be pragmatic in the next steps towards the lofty vision.
In short, Protocol Buffers were always a stop-gap to enable us to get something working, and it’s one we’re actively designing a replacement for, right now. You can see one public artifact of our design process in this GitHub discussion post.
This next step is to enable something we call “dynamic schemas” which allows for schemas to be defined/modified at runtime. Protobuf schemas are static. We want to get past that.
A couple of other interop-related initiatives:
we’re investigating Cambria and the evolution of lens-based solutions to schema transformation and investigating migrating to automerge in order to be closer to where the action is likely to be for further iterations of Cambria.
we have an open bounty to build a Matrix bridge for chat within DXOS so that we’re interoperable with Beeper and other Matrix-compatible chat clients.
In short, we’re interop maximalists, but we’re also trying to build a real thing that people use now.
Same!
I have so much more to say on this topic. I need to write more of it down, which I will endeavor to do. But would be open to discussing as well. Feel free to email me!
. Situations like this are why I think interoperability is so important. Solving this is only possible with Zero Data Apps. But the sad thing is that until there are enough apps (using the same protocol) to make this possible, end users won’t even realize it. It’s a chicken-and-egg problem at a market level :/.
.