2025-06 dev log

[michielbdejong]

• prepare work on wallet+vault for NPULS
• TUBS basics for Solid Slack Bridge #16

Leaving tasks module for next week

[michielbdejong]

Replied to the discussion in https://lists.w3.org/Archives/Public/public-solid/2025Jan/0042.html
Reading the docs that were linked in there.

Worked on https://github.com/michielbdejong/private-notes/blob/main/npuls-proeftuin.md#brainstorm

[michielbdejong]

Maybe https://perkeep.org/ is a good fit for "eduvault" or "edukeep" connected to "eduwallet".
Reading https://npuls.nl/actueel/interview-wat-een-eduwallet-kan-betekenen-voor-het-onderwijs/ (in Dutch)

[michielbdejong]

https://git-annex.branchable.com/

[michielbdejong]

or just SQL servers that follow each other's logs?

[michielbdejong]

Designing a life-long-data system from scratch for SURF:

• content-addressable data blobs
• content / timestamp / author like in willow
• git is a nice system to pick if you have to pick one, but we should support files as well as objects, see https://perkeep.org/doc/compare
• continuous sync (Merkle tree?)
• all of the above, sync any data between any systems with TUBS! :)
• SURF could offer a replica of all your data stores
• it needs to be learner-centric, but the easy part is we only care about read access
• it should have a separate system for sharing with third parties, but this system doesn't need to be as long-lived.
• creation, mobility, sharing.

[michielbdejong]

• git would be a very plausible transport and storage layer. things like perkeep and willow are more specific, git has been around for a long time and is not set to go anywhere (famous last words?) ;)
• on top of that, implement an add-only archiving tool. you could choose to do this at the git history level ("never purge the history"), or at the files level ("never delete a file") or at the lines level ("never remove lines from a file")
• some sort of pubsub apart from git push and git pull?
• mesh topology needs to be changeable over time. include it in each repo maybe?

[michielbdejong]

https://github.com/karser/gitbitlabhub uses webhooks instead of https://stackoverflow.com/a/3583114/680454 which uses commit hooks

[michielbdejong]

• push from one repo to another
• pull from one repo to another
• set up the remotes as a distribution tree (not bidirectional)
• Radicle project (talk)

[michielbdejong]

The user should be able to set up mirror policies.
If wallets already refer to files in git, then https://git-lfs.com/ might be a third layer. Maybe that's fine?
It should be possible to transport a commit via multiple redundant routes.
So instead of git clone, you're looking for something like git follow - multicast? https://git-annex.branchable.com/git-annex-multicast/

[michielbdejong]

it's fine though, there can be multiple commit hooks, and if a commit is received twice, it will be deduplicated in the merge.

Radicle does this with gossip+pull, I think we can just do it with multi-push.

[michielbdejong]

Once the data is replicated, via any number of hops, to the learner's latest data store, it will be easy to share via their wallet.
Check that the identity in the commit signature matches the issuer identity for the VC

[michielbdejong]

prevent remote deletes in git

[michielbdejong]

Back to rs-js - I was trying it out in remotestorage/myfavoritedrinks#15
remotestorage/remotestorage.js#1319 (comment)