Composing capability security and conflict-free replicated data types
![]()
![]()
This year, instead of participating in the Autumn Lisp Game Jam, Spritely decided to make some non-game demos to show off our tech. To that end, I spent the week of November 3rd writing GoblinShare, a secure, peer-to-peer file-sharing utility using the Guile port of Magenc for storage and distribution, relying on Goblins for the peer-to-peer connection abstraction, and delivered over Tor. Thanks to Goblins, this turned out to be super easy to implement. Let me show you how!
We’re excited to announce the release of Spritely Goblins 0.17.0! This release features a new lightning-fast persistence store called Bloblin, improved performance for persistence, and many bug fixes!
Today we're happy to announce the release of Goblins 0.16.1. This is a small patch release for the 0.16.0 release from a few weeks ago. Unfortunately, shortly after releasing it we discovered some issues which prevented using OCapN (the peer-to-peer networking element of Goblins) with Hoot. This release resolves that along with a couple of minor bug fixes.
We are excited to announce Spritely Goblins v0.16.0! This release of Goblins is faster than ever, with two major core speedups benefiting all Goblins-using programs! Furthermore, we have a brand new Unix Domain Socket netlayer, which means our OCapN protocol is now usable for efficient machine-local inter-process communication!
Over the past 6 months, Spritely has been busy bringing our message to new audiences. I thought it might be nice to compile a list for everyone to watch our talks. Christine Lemmer-Webber, the Executive Director of Spritely, has been busy giving most of these presentations, but the entire team has helped as well. The talks cover our technology, our values, our past, and our vision.
For those of us that use the Lisp family of programming languages, we have much appreciation for the humble pair. Using pairs, we can construct singly-linked lists and key/value mappings called association lists. Lists built from pairs have the pleasant property of being immutable (if you abstain from using setters!) and persistent: extending a list with a new element creates a new list that shares all the data from the original list. Adding to a list is a constant time operation, but lookup is linear time. Thus, lists are not appropriate when we need constant time lookup. For that, we need hash tables.