6D/ Common Features & Requirements of SSI-based Storage

Common Features & Requirements of SSI-based Storage

Session Convener: Charles Cunningham

Notes-taker(s): Dan Ostrovsky

Tags / links to resources / technology discussed, related to this session:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

• At least 5 SSI projects have converged on similar implementations… why? And how to share components?
• The most important components
  • Internal data model
    • IPLD - it’s what IPFS uses to create a json data of CID hash links to where data is stored, solving the problem if limited block size
    • What does IPFS add? Bitswap, a protocol to coordinate sharing of data.
    • This module could be shared across all projects, but it could have different feature sets that make it more complicated (i.e. fission does something different)
  • Authorization style
    • OCAP - object capabilities
    • ACLs don’t CA (access control lists don’t control access)
    • This module could easily be consumed across all projects
  • Identification style
    • DIDs are the industry standard
    • This module could easily be consumed across all projects
  • Replication style
    • When and how should graph synchronization happen?
  • Consistency
    • When and how should graph synchronization happen?
    • Projects implement eventual consistency
    • There are some issues with this, specifically when talking about authorization since more server attack vectors are introduced
  • Why are there 5 different projects with exactly the same styles (save Textile using ACL instead of OCAP for authorization style), and how could we standardize the formats/contents of implementations to interoperate between them?
  • Question was asked about EDV, which concerns itself with providing an https API