4 ms·

This kills the innovation or puts too much power to the first innovator. - if solid will dictate a protocol for data, it should cover the common denominator: s

This kills the innovation or puts too much power to the first innovator. - if solid will dictate a protocol for data, it should cover the common denominator: so if you have your email on gmail now, lets say solid is covering basic email structure, i can move my email data to another provider, but about my filters? On other tiny stuff that gmail builds on email - if i invent something new in a chat app, lets say stickers. I implemented that. (Should I ask solid to update protocol for this) Now all other chat apps supporting solid, has to follow my lead? Interoperability will be hell to manage. - even with the limited number of browsers, we couldn't manage to unify the protocol. Protocol stuff is real hard.

black_puppydog 7y ago
Not saying this is not hard, but I assumed (without having read into it) that the protocol solid itself is much more low-level than that. What you're describing sounds more like owncloud's level of operation: we host email / we host pictures I'd expect Solid (or any competing protocol) to provide very low-level access to "data" in some form. A third party (let's call them smail) would then provide the service "send and receive email" (to stay with your example, although I'm unsure email is a good fit). Crucially, the value that service adds would not be hosting and backing-up of your email, but rather just the interface and functionality. Ideally, all the data would still be hosted on your pod. When smail does indexing of your email, they load them from your pod (after you granted them access to that data) and do their thing. The difference to now being that at any time, you could choose a different provider that provides a different interface to the same underlying data. As I said, I didn't read into it, but that's what I would expect.
- bluesign 7y ago
  "Crucially, the value that service adds would not be hosting and backing-up of your email, but rather just the interface and functionality" Yeah but doesn't that create a problem, vendor lock-in. Let's imagine we managed to separate data into 2 parts (which I suppose pretty hard), content and meta-data ( by meta i mean service specific information ) Let's say, if I label an email in gmail, it is meta (service specific data), should gmail store this in my pod? - if gmail will store this on their data center, it would lead to vendor lock in. - if gmail will store this in my pod, in a service specific container. Can they use their own spec? Or will they store this with data with extensions ( XMPP all over again ) Now imagine they chose the second one, I migrated to smail (imagine they decided to go for folders instead of labels), do they have to do some migration on my data? What if I go back to gmail again? Or I decide to use gmail one day, smail another? Tbh email is the most easiest situation here, as it has some kind of global standard, Twitch vs Youtube case would be more complicated.
  - anderspitman 7y ago
    I think of solutions like Solid more like traditional filesystems. Many file formats exist for things like images, and yet there are lots of apps that work with these formats.
thinkloop 7y ago
> Should I ask solid to update protocol for this I imagined it more like a schemaless database. Apps could save and use whatever data in your pod without any protocol changes. > i can move my email data to another provider, but about my filters? On other tiny stuff that gmail builds on email The other provider would provide those integrations, or a superior competitor will. > Now all other chat apps supporting solid, has to follow my lead? I don't think there is any mandatory integration. I think apps can choose the level of integration they implement. Maybe a feature of your app is that it purposely removes/ignores stickers, so you don't integrate. Another app may be all about stickers and even lets you augment and modify them, so it integrates heavily.
- bluesign 7y ago
  "I imagined it more like a schemaless database." schemaless database would destroy the system immediately. All providers putting their own meta-extensions will make my pod trash "The other provider would provide those integrations" Yeah but imagine I moved from gmail to let's day new competitor smail, let's say they implemented filters too. Now they have 2 options, import my gmail filters, make new data structure as their own, or all the time support gmail filter structure with its limitations. In both cases there is no happy ending, supporting N different data structures is not easy work. Cloning of the data is more disaster in the end.
  - thinkloop 7y ago
    > All providers putting their own meta-extensions will make my pod trash This is the way the world is now except that you don't even have the data. Otherwise you bring up some good points. I imagine the answer is that sites will be incentived to cooperate with each other creating informal mini standards along the way. Sites that disagree with the standards can build their own data structures but won't be able to leverage existing networks, so it better be worth it. Eventually you could have different flocks of semi-interrelated apps that each act on various parts of the shared data structure.
  - Existenceblinks 7y ago
    Pod owners will have to do things like api client libs developers are doing; creating a bunch of adapters.
Vinnl 7y ago
> but about my filters? On other tiny stuff that gmail builds on email All that is data, so those, too, could be stored in your Pod and brought along with you. > Should I ask solid to update protocol for this No, interoperability can be achieved through your data model, which is yours to decide - Solid doesn't dictate the shape of your data. But as you noted, only competing apps using the same data model will be interoperable - stickers won't suddenly appear without the developer implementating them. (Disclosure: I also work for Inrupt, but views are my own.)
- brongondwana 7y ago
  Speaking of email in particular, I'd be keen to chat to you lot about the JMAP protocol, which is hoping to provide some of the "modern data model" around email (and we're now working on Calendars)
  - Vinnl 7y ago
    The best thing there would probably be to reach out to the Solid community in general, through either the forums [0] or the chat [1]. [0] https://forum.solidproject.org https://forum.solidproject.org [1] https://gitter.im/solid/chat https://gitter.im/solid/chat
    - brongondwana 7y ago
      Thanks, I sent an email :) Being as how I'm into email and all that.
erikpukinskis 7y ago
The first innovator has already come and went along with dozens of others. It’s not a new idea. If Solid wins the market, they will have earned their position by overcoming incredible odds and offering something millions of people want. This thread is full of people arguing how unlikely that is, so if it comes to pass, it will say something much more about Solid than “they were first”.

black_puppydog 7y ago

Not saying this is not hard, but I assumed (without having read into it) that the protocol solid itself is much more low-level than that. What you're describing sounds more like owncloud's level of operation: we host email / we host pictures I'd expect Solid (or any competing protocol) to provide very low-level access to "data" in some form. A third party (let's call them smail) would then provide the service "send and receive email" (to stay with your example, although I'm unsure email is a good fit). Crucially, the value that service adds would not be hosting and backing-up of your email, but rather just the interface and functionality. Ideally, all the data would still be hosted on your pod. When smail does indexing of your email, they load them from your pod (after you granted them access to that data) and do their thing. The difference to now being that at any time, you could choose a different provider that provides a different interface to the same underlying data. As I said, I didn't read into it, but that's what I would expect.

bluesign 7y ago
"Crucially, the value that service adds would not be hosting and backing-up of your email, but rather just the interface and functionality" Yeah but doesn't that create a problem, vendor lock-in. Let's imagine we managed to separate data into 2 parts (which I suppose pretty hard), content and meta-data ( by meta i mean service specific information ) Let's say, if I label an email in gmail, it is meta (service specific data), should gmail store this in my pod? - if gmail will store this on their data center, it would lead to vendor lock in. - if gmail will store this in my pod, in a service specific container. Can they use their own spec? Or will they store this with data with extensions ( XMPP all over again ) Now imagine they chose the second one, I migrated to smail (imagine they decided to go for folders instead of labels), do they have to do some migration on my data? What if I go back to gmail again? Or I decide to use gmail one day, smail another? Tbh email is the most easiest situation here, as it has some kind of global standard, Twitch vs Youtube case would be more complicated.
- anderspitman 7y ago
  I think of solutions like Solid more like traditional filesystems. Many file formats exist for things like images, and yet there are lots of apps that work with these formats.

thinkloop 7y ago

> Should I ask solid to update protocol for this I imagined it more like a schemaless database. Apps could save and use whatever data in your pod without any protocol changes. > i can move my email data to another provider, but about my filters? On other tiny stuff that gmail builds on email The other provider would provide those integrations, or a superior competitor will. > Now all other chat apps supporting solid, has to follow my lead? I don't think there is any mandatory integration. I think apps can choose the level of integration they implement. Maybe a feature of your app is that it purposely removes/ignores stickers, so you don't integrate. Another app may be all about stickers and even lets you augment and modify them, so it integrates heavily.

bluesign 7y ago
"I imagined it more like a schemaless database." schemaless database would destroy the system immediately. All providers putting their own meta-extensions will make my pod trash "The other provider would provide those integrations" Yeah but imagine I moved from gmail to let's day new competitor smail, let's say they implemented filters too. Now they have 2 options, import my gmail filters, make new data structure as their own, or all the time support gmail filter structure with its limitations. In both cases there is no happy ending, supporting N different data structures is not easy work. Cloning of the data is more disaster in the end.
- thinkloop 7y ago
  > All providers putting their own meta-extensions will make my pod trash This is the way the world is now except that you don't even have the data. Otherwise you bring up some good points. I imagine the answer is that sites will be incentived to cooperate with each other creating informal mini standards along the way. Sites that disagree with the standards can build their own data structures but won't be able to leverage existing networks, so it better be worth it. Eventually you could have different flocks of semi-interrelated apps that each act on various parts of the shared data structure.
- Existenceblinks 7y ago
  Pod owners will have to do things like api client libs developers are doing; creating a bunch of adapters.

Vinnl 7y ago

> but about my filters? On other tiny stuff that gmail builds on email All that is data, so those, too, could be stored in your Pod and brought along with you. > Should I ask solid to update protocol for this No, interoperability can be achieved through your data model, which is yours to decide - Solid doesn't dictate the shape of your data. But as you noted, only competing apps using the same data model will be interoperable - stickers won't suddenly appear without the developer implementating them. (Disclosure: I also work for Inrupt, but views are my own.)

brongondwana 7y ago
Speaking of email in particular, I'd be keen to chat to you lot about the JMAP protocol, which is hoping to provide some of the "modern data model" around email (and we're now working on Calendars)
- Vinnl 7y ago
  The best thing there would probably be to reach out to the Solid community in general, through either the forums [0] or the chat [1]. [0] https://forum.solidproject.org https://forum.solidproject.org [1] https://gitter.im/solid/chat https://gitter.im/solid/chat
  - brongondwana 7y ago
    Thanks, I sent an email :) Being as how I'm into email and all that.

erikpukinskis 7y ago

The first innovator has already come and went along with dozens of others. It’s not a new idea. If Solid wins the market, they will have earned their position by overcoming incredible odds and offering something millions of people want. This thread is full of people arguing how unlikely that is, so if it comes to pass, it will say something much more about Solid than “they were first”.