-
Notifications
You must be signed in to change notification settings - Fork 6
Open Problem: Mutable Data (Naming, Real-Time, Guarantees) #6
Conversation
OPEN_PROBLEMS/MUTABLE_DATA.md
Outdated
### Within the IPFS Ecosystem | ||
> Existing attempts and strategies | ||
|
||
##### IPNS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hugomrdias @aschmahmann where can I find your latest slides, talks and notes on IPNS with multiple routers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also include:
- [Improve IPNS spec]Improve IPNS spec ipfs/specs#205)
- IPNS-over-PubSub as an Independent Transport
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also this issue: ipfs/specs#198
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parts of this open problem read a little too open. This can be improved over time but I think we'd benefit from formalising things a little narrower and a little more explicitly.
Co-Authored-By: Jorge Soares <[email protected]>
Co-Authored-By: Jorge Soares <[email protected]>
Co-Authored-By: Jorge Soares <[email protected]>
Co-Authored-By: Jorge Soares <[email protected]>
Co-Authored-By: Jorge Soares <[email protected]>
Co-Authored-By: Jorge Soares <[email protected]>
|
||
Mutable Data is a fundamental building block for creating applications. Improving the existing solutions and creating new ones that support a large user set in a distributed context will enable the growing number of Internet users to be part of the dWeb. | ||
|
||
### What defines a complete solution? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not necessarily happy with this section. I feel it is not clear enough on how ambitious and challenging solving this Open Problem is.
@jsoares @yiannisbot Would you like to review and make some suggestions? I'm out of creative juice :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TLDR: A complete solution for mutable data (in a p2p context) is pretty unreasonable given that we don't have a one-size-fits-all solution in the centralized world.
I suspect that the reason it's not clear is that there isn't (or has not yet been defined) a one-size fits all answer for what mutable structures should look like or how they should work. Some examples:
- What form of access control/capabilities even makes in a non-centralized context?
- Consensus, eventual consistency, causal consistency, etc.
- Should ACLs be changeable?
- If cryptography is utilized for ACLs how is it upgraded?
- What assumptions can people work with?
- This problem maps really closely with solving distributed identity, but most solutions assume pre-distributed identity... it's a bit of a contradiction
- If cryptography is utilized which types are ok, which math is sufficient
- How do people find new mutable data?
- This might seem unrelated, but given its tie into the identity problem as well as potential forking of mutable data streams it's pretty important
I suspect that step 1 in any "complete solution" is defining the tradeoffs and composability properties of solution categories. This is perhaps a combination of something like ipfs/notes#379 with a more precise version of the Zooko's triangle tradeoffs (it is notoriously underdefined/specified and could probably be more complete if explicitly correlated to the CAP theorem).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the notes @aschmahmann! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took your notes, restructured a bit and expanded the section more. Thank you!
@yiannisbot @jsoares your feedback is still very welcome. I'll go ahead and call this one done, PRs are always accepted :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yiannisbot @jsoares your feedback is still very welcome. I'll go ahead and call this one done, PRs are always accepted :)
Happy to have a look, but can only do tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a bunch of language fixes but those can wait for @yiannisbot's comments. The version incorporating Adin's comments is already much more detailed but, as acceptance criteria for an RFP, it's still fuzzy.
Saying that being the easy part, coming up with objective criteria probably requires some discussion of system parameters and requirements, which is not critical at this stage but should be done at the RFP drafting stage (see nice example here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as acceptance criteria for an RFP, it's still fuzzy.
..
which is not critical at this stage but should be done at the RFP drafting stage (see nice example here).
Exactly, this docs is not the RFP and more broad in nature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that step 1 in any "complete solution" is defining the tradeoffs and composability properties of solution categories. This is perhaps a combination of something like ipfs/notes#379 with a more precise version of the Zooko's triangle tradeoffs (it is notoriously underdefined/specified and could probably be more complete if explicitly correlated to the CAP theorem).
@aschmahmann: during the ACM ICN conference in Macau, we briefly discussed on Zooko's triangle and how we can model naming approaches around it, i.e., the fact that it's difficult (impossible?) to have "one size fits all" solution. Do you remember any more details on this discussion? I think it's going to be useful as we formulate this Open Problem, but I can't recall much from our discussion :)
No description provided.