Solid infrastructure for managing all my pods as well as pod-to-pod interlinks? [Support for Subsidiary Ledgers and Business Documents]
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 563
- Forks
- 108
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 3
Description
Context
This is partly a user experience issue/question dealing with the ability to project/support:
- some sort of automatic decentralized registry where I can find all of my pods (something like this experience in Groove Workspace https://www.youtube.com/watch?v=lOAY0fOfNNc)
- pods being children of parent pods (ideally using the same registry mentioned above)
The specific use case I have in mind is being able to support Subsidiary Ledgers capable of storing/referencing billions of business documents like all of the invoices, purchase orders, waybills, delivery confirmations, etc. found in a large corporation (e.g. Microsoft, Apple, US Government, ...) ...in the "fullness of time", every business documents on the WWW/Internet/in the universe.
Questions
- Suggestions for how to architect the Subsidiary Ledgers use case from a Solid pod data architecture perspective?
- Can individual items of content be stored in a signed, easily verifiable, and updatable manner?
- What is the physical scalability limits envisioned for a single pod?
- Can a single instance of an item appear to live in multiple folders and multiple folders across multiple pods? I understand the concept of linking ...but digging deeper, should I consider creating a bottom level of physical content pods for storing the business documents as they arrive and as they are created within the organization? ...and then one or more layers of "linking" pods above that (that instantiate the hierarchy of Subsidiary Ledger folders)?
- On the other end of the scale, is it conceivable that each and every business document (plus supporting documents and business process execution history) could live in its own pod? Is this a realistic architecture/design? ...i.e. every large organization having billions and billons of business document pods?
That's a good list to start with.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the Solid specification and the issue's questions about pod discovery, parent-child relationships, signed content, scalability, cross-pod links, and per-document pods. Done would require a settled architecture or documented answers for the proposed subsidiary-ledger use case, but no specific file or test is identified.
Written by the indexing model from the issue text.
Assessment
- Domain
- distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100