Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local-first resources - don't require a server when creating a resource #998

Open
joepio opened this issue Oct 23, 2024 · 0 comments
Open

Comments

@joepio
Copy link
Member

joepio commented Oct 23, 2024

Problem

Creating a new resource requires a lot: an active internet connection, a working server, a resolvable Agent. It would be nice if Resources can be created and update local-first.

Additionally, it would be nice if resources could be resolved without a server. A P2P solution, perhaps something that uses content-addressing (e.g. something like ipfs / iroh) would be swell.

Potential solution

  • User can create a Commit that does not refer to an HTTP subject. It has no target. It's a RootCommit (not sure about the name).
  • The signature of that commit is the identifier. (or perhaps the iroh hash?)
  • This RootCommit has a date, a publicKey (linking
  • You can refer to the initial version of this resource using a did:atomic:RootHash. So we'll introduce a new did:atomic schema for this.
  • You can refer to a specific following version of this resource using using a did:atomic:CommitHash
  • We still want pretty URLs, in some usecases, of course! So how do we deal with that? How do we map these?
  • We can still resolve using HTTP: https://atomicdata.dev/cid/aeg8ae9gyg98ea9eahge98gha

API

Not a lot would change for the user. When creating a resource, the subject becomes optional. The resource that is returned will get a subject through its constructor, by taking the hash of that resource.

Questions

  • Should the identifier of the resource be based on the signature of the first resource? Or should it be the hash? For compatibility with something like ipfs, a hash would be nice. But Atomic uses signatures of the agent.
  • For authorship, the public key (or subject?) of the signing agent should be included in that initial resource.
  • What kind of merge algo should we use for branching and resolving commits?
  • Should we merge with nextgraph to fix this too? Merging with NextGraph #1012

Relevant issues

Relevant reads

  • AnySync, the protocol that syncs AnyType. A CRDT that uses IPFS under the hood.
  • Willow, powered by iroh. Has rust and ts implementations.
  • Loro. CRDT with Rust and TS libraries. Seems to be fast and lightweight, compared to yjs / automerge.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant