First draft for apps data protocol #1
Conversation
| ### Scope (WIP) | ||
|
|
||
| - Should only rely on existing features of Swarm, but might evolve as new possibilities are added | ||
| - Should be usable via a HTTP gateway |
There was a problem hiding this comment.
What does this mean exactly? No PSS like functionality can be used?
There was a problem hiding this comment.
I think the core protocols should work with the "minimum service" provided by Swarm, but additional functionalities could use additional Swarm capabilities as they are available.
For example we could have a communication channel between 2 contacts that uses feeds by default, but users could opt-in to send messages over PSS as well for faster interactions.
What do you think?
There was a problem hiding this comment.
Ah ok, I understand what you mean and this absolutely makes sense.
|
|
||
| #### Data structure format | ||
|
|
||
| - Should we use JSON or a binary format such as protocol buffers? |
There was a problem hiding this comment.
Both has advantages and disadvantages. With JSON
- it's easy to use from any programming language
- it can be self descriptive
- it's usually not well-defined or standardised, so things like schemas or signatures are more complicated
With binary:
- A schema can be used and enforced
- Need more tooling to use/debug and this can be more complicated when developing cross-platform apps
- Better performance, especially when dealing with more data
I think at the early stage of a protocol it's better if adoption is easier and in that case JSON seems a better choice.
There was a problem hiding this comment.
👍 Let's start with JSON and we can reevaluate if performance or schema enforcement becomes a problem.
|
|
||
| - Define what entities should be part of core vs extensions. | ||
| - Define validation rules for these core entities. | ||
| - Define discover and exchange rules for these entities. |
There was a problem hiding this comment.
What do you mean by discover and exchange rules?
There was a problem hiding this comment.
I mean if Alice wants to contact Bob, the protocol should define "where" (basically the feed parameters) Alice should write so that Bob can discover it, and what encryption keys they need to use.
| #### Data encryption | ||
|
|
||
| - Should a single algorithm or multiple ones be supported/recommended? | ||
| - Should Swarm built-in encryption and/or ACT be used? |
There was a problem hiding this comment.
I would prefer to use light nodes everywhere and use Swarm's built-in encryption.
However light nodes are not going to be production ready for a while and there may be always use-cases where they are not feasible to use (think of embedded devices). Also I can imagine hybrid products and solutions that are not completely decentralized but are using Swarm as a storage layer and therefore using gateways to access data.
For those cases it would be good to have a protocol level, standardised encryption layer to provide end-to-end encryption. I was thinking of somehow using Swarm's encryption code for that but the encryption in Swarm is tightly coupled with how the files are stored so I assume it would come with a big dependency on other components (think of chunker, hashing etc).
There was a problem hiding this comment.
I agree light nodes are the best option but I think it would be good to start working on these protocols based on the current version of Swarm so we are not limited by Swarm's development timeline, though obviously as new features are released we should adapt accordingly.
I think the question is also if we want to support Web apps hosted on Swarm and accessed using a Web browser via a Swarm gateway?
Personally I'd rather not support this use case because I think there are too many potential security and privacy risks, but at the same time if this is a primary use-case for Swarm I think these protocols should support it in order to be relevant.
There was a problem hiding this comment.
Well, again it's the question of adoption. Assuming installing something decreases the willingness of people to try out new things, I think most people will use their first dapps from the browser. And until the majority of the browsers don't support Swarm the only option is a gateway.
I also understand the risks you mentioned with this but if we already have implementations in Javascript I don't see a reason why the browsers should not be supported. Regarding the protocol this doesn't require too much effort on our side, for example in the case of encryption the only requirement is to choose a standard which has a Javascript implementation which is also supported in the browser.
What do you think?
There was a problem hiding this comment.
Yes I think it's OK to be cautious about not defining requirements that would prevent usage in Web browsers, I guess I'm mostly concerned about developers hosting their apps using a gateway, that would completely undermine security and privacy measures the protocols would otherwise define.
No description provided.