poc for KVS #1

Closed
opened 2025-12-17 11:01:40 +00:00 by despiegk · 1 comment
Owner
  • a key value store
  • per value we can say which user can write/admin
    • if admin can add new groups to write (suggest to only allow groups)
  • basic groupmgmt on holo (groups with members, member can be group or user)
  • each user is linked to one or more mycelium pub ip addresses
  • default: user who writes is admin
  • key is dot notation and has meaning as given by author
  • an existing key cannot be overwritten unless is admin

questions

  • links holochain ???
  • can we put client & holochain app do in 2 binaries? (holo functionality embedded in server)
  • if we stay with the webassembly way, what might be better how do we push new apps?
- a key value store - per value we can say which user can write/admin - if admin can add new groups to write (suggest to only allow groups) - basic groupmgmt on holo (groups with members, member can be group or user) - each user is linked to one or more mycelium pub ip addresses - default: user who writes is admin - key is dot notation and has meaning as given by author - an existing key cannot be overwritten unless is admin questions - links holochain ??? - can we put client & holochain app do in 2 binaries? (holo functionality embedded in server) - if we stay with the webassembly way, what might be better how do we push new apps?
Member

The code base is updated to maintain a key value store, where each entry (key) has both a value and an associated ACL. The ACL defines 2 permissions: write and admin. Write allows updating the value of the key, while admin can update the ACL and delete (tombstone) the key. ACL members can either be a group (defined by a name and members, must be created first) or a single user. Groups can have other groups as members (up to a depth of 16). A user is defined based on his mycelium IP address (derived from an x25519 public key). Write actions must provide a signature with the corresponding private key to prove the identity. A nonce is recorded on each entry to avoid replay attacks.

Signing using x25519 is not possible natively (x25519 is used for ECDH). To work around this, we use VXedDSA, specifically the signal variant: https://signal.org/docs/specifications/xeddsa/#vxeddsa. There are some changes though (compared to a recent but not really used rust implementation, but that one is not compatible with wasm). For one, we fix the sign bit of the converted ed25519 key to 1 instead of 0. Other than that, the hash function is not the same as the spec since the popular dalek libraries don't expose the field arithmetic, and the elligator 2 group used there is said to be deprecated. The intent of the hash function (remap the base point on the curve) is the same though and doesn't seem to break, but this is not a formally audited solution. This functionallity has been put into a separate crate in this lib (with a separate feature to enable signing functionality since that relies on OS stuff, so that won't work on wasm, wasm only validates signatures).

There is a small CLI tool which takes care of generating the signatures properly.

Links allow an app to link 2 values together. The DHT essentially stores hashed keys. Without links, it would be possible to load a given key (since it is known and thus can be hashed), but list would not be possible since we can't find random hashes in the data spaces). With links, we can use an anchor(known value), to link all our keys to, which allows us to list all keys by traversing all links from our known anchor. Essentially, data storage is a giant HashMap, and links allow us to build a graph on top of it

Client embedding

Cliend and holochain could be embedded together in theory. In production setups though, we'd likely need to upload the app to running instances using a holochain interface.

The code base is updated to maintain a key value store, where each entry (key) has both a value and an associated ACL. The ACL defines 2 permissions: write and admin. Write allows updating the value of the key, while admin can update the ACL and delete (tombstone) the key. ACL members can either be a group (defined by a name and members, must be created first) or a single user. Groups can have other groups as members (up to a depth of 16). A user is defined based on his mycelium IP address (derived from an x25519 public key). Write actions must provide a signature with the corresponding private key to prove the identity. A nonce is recorded on each entry to avoid replay attacks. Signing using x25519 is not possible natively (x25519 is used for ECDH). To work around this, we use VXedDSA, specifically the signal variant: https://signal.org/docs/specifications/xeddsa/#vxeddsa. There are some changes though (compared to a recent but not really used rust implementation, but that one is not compatible with wasm). For one, we fix the sign bit of the converted ed25519 key to 1 instead of 0. Other than that, the hash function is not the same as the spec since the popular dalek libraries don't expose the field arithmetic, and the elligator 2 group used there is said to be deprecated. The intent of the hash function (remap the base point on the curve) is the same though and doesn't seem to break, but this is not a formally audited solution. This functionallity has been put into a separate crate in this lib (with a separate feature to enable signing functionality since that relies on OS stuff, so that won't work on wasm, wasm only validates signatures). There is a small CLI tool which takes care of generating the signatures properly. ## Holochain links Links allow an app to link 2 values together. The DHT essentially stores hashed keys. Without links, it would be possible to load a given key (since it is known and thus can be hashed), but list would not be possible since we can't find random hashes in the data spaces). With links, we can use an anchor(known value), to link all our keys to, which allows us to list all keys by traversing all links from our known anchor. Essentially, data storage is a giant HashMap, and links allow us to build a graph on top of it ## Client embedding Cliend and holochain could be embedded together in theory. In production setups though, we'd likely need to upload the app to running instances using a holochain interface.
lee closed this issue 2026-01-09 10:55:33 +00:00
Sign in to join this conversation.
No labels
No milestone
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
geomind_research/holo_ledger#1
No description provided.