Finished all the rest of the #Spritely Crystal client subcommands right before I have to get ready for this meeting, heck yes.
Documentation is next (after the meeting)
Finished all the rest of the #Spritely Crystal client subcommands right before I have to get ready for this meeting, heck yes.
Documentation is next (after the meeting)
YES
I can finally read and write using the #Spritely Crystal client to the encrypted store and the registry via the command line. IT WORKS.
Ok, only two things left for the #Spritely Crystal client to be out:
- Need to handle fetching specifically requested versions by grabbing them from the URL (since that data can appear there anyway)
- Need to finish the stub of the "client" stuff itself, ie just the argument parsing and printing out data to the user. That stuff is fairly easy.
#Spritely Crystal http "registry" server appears to work right now, as does the client-interface api (which means actual command line tool is next)
Generation 1 of #Spritely Crystal read-only URLs are approx 142 characters long. Not short. Can get shorter in generation 2 though, I think.
Some of the major sources of inspiration for #Spritely:
- ActivityPub (unsurprisingly)
- the E programming language https://librsync.github.io/rdiff.html
- The "Rees thesis" showing that ocaps are actually just sane lexical scope behavior http://mumble.net/~jar/pubs/secureos/secureos.html
- tahoe-lafs https://tahoe-lafs.org/trac/tahoe-lafs
- freenet https://freenetproject.org/pages/documentation.html
- MUDs/MOOs/etc http://www.hayseed.net/MOO/
- SPKI/SDSI http://world.std.com/~cme/html/spki.html
- The Agoric Papers http://e-drexler.com/d/09/00/AgoricsPapers/agoricpapers.html https://agoric.com/references/
#Spritely Crystal server pushed https://gitlab.com/spritely/crystal/blob/master/crystal-server.rkt
But the bulk of the logic it uses is from https://gitlab.com/spritely/crystal/blob/master/crystal.rkt
Command line client that talks to a running server coming up next.
Ok.
- turned on The Good Music
- got some snax, not too high calorie
- more tea is made
I can do this.
I will knock out the #Spritely Crystal client this afternoon.
Just watch me.
I'm pretty excited about #Spritely Crystal. I guess it'll be clearer what it is once it's available but it shows off that mutable, peer-to-peer, server-failure-friendly, and securely private updates are possible in something like the fediverse.
It also exposes a whole lot of problems about the possibility of conflicting updates. But as Crystal will make clear (if not crystal clear, ha), those problems *already exist* on our current fediverse, and are mathematically hard to remove. Embrace it!
Time to make the #Spritely Crystal client today.
This first version of the #Spritely Crystal "mutable references in immutable storage" system will use the quartz: URI scheme. That's because I know it's not the optimal version; I can improve things dramatically once I switch it from RSA -> elliptic curves (that one will be using the topaz: uri scheme). But I did the initial implementation using RSA and I want to get it out the door.
related to sha256 -> sha256d change, I also changed the URNs in magenc over to urn:sha256 -> urn:sha256d #spritely #magenc
Promises, continuations/coroutines, and re-entrancy (an email/some pondering to cap-talk) https://groups.google.com/forum/#!topic/cap-talk/cJwUrnzX0lk
This is related to design decisions for #Spritely Goblins.
So the downside to this is: the lessons taken from that read of things will probably mean a couple more days of refactoring of #Spritely Crystal, delaying the demo/docs a small amount.
However I think it's worth it to do things right.
Re-reading the Tahoe-LAFS paper and Tahoe URI pages https://eprint.iacr.org/2012/524.pdf https://tahoe-lafs.readthedocs.io/en/tahoe-lafs-1.12.1/specifications/uri.html
Glad I did, found several things I needed to fix or improve for the #Spritely Crystal demo
I pushed the #Spritely Crystal repo up https://gitlab.com/spritely/crystal/blob/master/crystal.rkt
I uploaded it because some folks have said they wanted to see it... but it is *not* ready for human consumption yet. Not documented, not usable, but I've verified the core ideas work now. More as this and next week progress.
Okay, I can finally write "new" versions of files in #Spritely Crystal (tahoe-lafs / freenet like mutable p2p distributable files that *don't* have consistency guarantees) and then retrieve them again.
I think this will be a useful demonstration of both some cool things we can do in p2p systems and the ways CAP tradeoffs get in the way... and how those tradeoffs reappear everywhere throughout our systems.
I moved Magenc's writeup to its repository, currently in the README file. https://gitlab.com/dustyweb/magenc/blob/master/README.org
Also merged two PRs from @clacke (thank you!)
Next question: I guess at this point I should magenc a #Spritely project proper and move it over?
I'm not sure in what order #Spritely things will come out. I expect a series of regular releases, but *what* comes out will be whatever is most convenient for me to release at that point.
Near term possibilities:
- Crystal: How can we bring updateable content to p2p systems? Inspired by Tahoe-LAFS and Freenet's updateable content, but simplified for easy explanation.
- Crystal Golem: The Golem demo, but now using Crystal URIs!
- Humanoid: a bare-bones ActivityPub implementation tutorial
At TPAC in 2017, someone asked me, what would I do if I could work on what I was really interested in and cared about? I sheepishly admitted that, well, I'd like to work on social networks as a distributed virtual world / game.
I thought I'd be laughed out of the room. Instead, it turned out that almost everyone I was working with had background in that space. Even the ocap stuff I'd been studying came largely from Electric Communities Habitat.
That gave me the courage to pursue #Spritely.
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.