Goblins makes writing secure distributed programs easier and safer, even in a mutually suspicious network. Its quasi-functional nature gives it easy transactionality and even time travel. (Yes, time travel!)

Goblins implements CapTP, the Capability Transport Protocol, which has such features as distributed acyclic garbage collection and reductions of network round trips through promise pipelining. But its biggest feature is how easy it is to write safe distributed code, which by following object capability security, which mostly resembles normal programming patterns of passing around object references.

Goblins is implemented as a Racket library (though a port to Guile is planned, and we are hoping for CapTP interoperability with Agoric's implementation of CapTP) and is heavily inspired by the E programming language. It is the most foundational layer of Spritely.

Porta & Bella allow for the storage and distribution of files while keeping their contents only known to those who have been authorized to access them by receiving the appropriate capability URI. Porta refers to our mushroom friend, who provides immutable file storage, and Bella refers to the vine, who allows for updates by stringing together multiple Porta entries.

In addition to their security properties, Porta & Bella allow for portability because the names of such files aren't dependent on where they live. No matter if the files are kept on your hard drive, on your personal server, on a cloud service provider, over existing content-addressed systems (like IPFS), or stuffed in a USB key in a shoebox under your bed (or all of the above), the same Porta-Bella URI can refer to all of them.

This means, for instance, that if nodes go down on the ActivityPub network but both their contents and profiles are stored as Porta-Bella documents, users can easily point their account at a new server without a loss of functionality or history. (See the Golem demo as an example.) Combining Bella updateable documents with ActivityPub profiles is therefore also a practical decentralized identity solution.

Note that Porta and Bella at this point have been prototyped and their functionality demonstrated, but this prototype is not ready for public use, with their implementations subject to change. The prototypes went under the names of Magenc and Crystal and will be renamed soon. The Porta-Bella design is derived largely from the Tahoe-LAFS project, but a bit tuned more to the needs of Spritely. It is highly likely that ERIS will be used as the future foundation of this work.

If you've ever looked at decentralized identity systems, you've probably noticed that their names look like a bunch of gibberish letters and numbers. Unfortunately this is the tradeoff that decentralized identity must take: in order to be globally secure and decentralized, we have to sacrifice human-meaningful names. (See Zooko's triangle for the theoretical background of why this is.)At first glance, this seems like a real problem, because what is the point of our systems if they aren't meaningful to humans?

Brux is a petnames system for Spritely, and it fills this need much the same way the contact list on your phone does: you don't need to memorize all phone numbers, because your phone provides a locally meaningful mapping of names to numbers for you. That's exactly what petnames are: locally meaningful names mapped onto a global system. However petname systems provide more functionality: you can leverage your social network to discover other participants in the network. (It turns out that petname systems also help prevent phishing attacks... what a great bonus!)

Brux development is in its early stages but we have a functioning prototype which integrates with goblin-chat. We have also written a whitepaper explaining Petnames and a (less completed, but analyzed and well outlined) whitepaper on how to build secure user interfaces that resemble existing social network UIs.

We want to make it easy to hook together programs written in Goblins to the existing ActivityPub speaking federated social network. Thankfully this should be a very clean mapping, because both Goblins and ActivityPub follow the classic actor model. Mandy's design is to bridge the worlds of distributed Goblins programs and ActivityPub by providing an easy mapping between them.

In the process we can add richer interactions and better protections against abusive behavior (and better support for cooperative, intentional behavior) than currently exist in the ActivityPub ecosystem. See the OcapPub writeup for some of these ideas (most of those do not require Mandy to implement them, but Mandy will make implementing them much easier).

Hyptis provides distributed small-world finance systems, appropriate for use in games or for communities such as your neighborhood mutual aid network.

Hyptis builds upon object capability financial theory which is well-researched and easy to implement on top of a distributed ocap style system such as Spritely Goblins. As said, we're aiming for small-world financial systems (though the folks at Agoric are putting in work on large-world financial systems, and if we achieve CapTP interoperability with them, their systems should be usable through Spritely as well). However, it is amazing how much can be easily done in such a small amount of code with Goblins' design: a simple money implementation which preserves transactional integrity even in the event of errors and allows for account holders to have access from across a network can be implemented in as little as 25 lines of code in Goblins... no blockchain required! (This design is ported directly from the Capability-based Financial Instruments document.)

Wouldn't it be a travesty if someone built an amazing looking fire elemental monster that you really want to put in your game, but you're afraid that if you add it that it'll upload all your passwords and credit card information to some unsavory individuals and then proceed to delete all the files on your system?

The general perspective in computing is that if you run untrusted code, and that untrusted code wants to do something dangerous (whether maliciously or due to unintentional bugs), you're hosed. But it doesn't have to be that way.

Oaken has yet to be written, but its plan is based off of the Emaker design from E and the Frozen Realms proposal for Javascript.

Here's where Spritely becomes extra fun... where social networks meet games! After all, modern social networks are merely degenerate versions of virtual worlds... you can chat and send messages in both, but you can't go solve ghost mysteries with your friends or fight monsters or hand your friend a drink that makes them dizzy when they drink it. These days we have distributed social networks and virtual worlds, but no well developed combination thereof. Fantasary aims to change that, while returning a sense of fun and collaboration to online spaces. By building worlds with your friends, Fantasary should provide an environment to explore fun environments and also explore learning to program as an educational and cooperative tool. (Not to mention getting secure communication tools in the hands of users in a way that seems fun!)

This is admittedly both the most complex and ambitious piece of the Spritely system (though also the most exciting). However, it is possible to be built; in the mid-to-late 1990s, Electric Communities Habitat did exactly this, but the company closed before it achieved all of its goals, and it was a proprietary system (whereas of course everything in Spritely is free and open source software).

But this is also a good example of why building something this ambitious is worthwhile: as a driver for powerful and interesting technology. After Electric Communities Habitat closed, its ideas lived on in the E programming language, which we have already said that Goblins is built upon (as are many other ideas in Spritely). Thus in this case, even failure can be a path to success if it advances the tooling for distributed social networks in general.

Two demos are planned for Fantasary to come out between 2021 and 2022: a textual virtual world demo (similar to but more sophisticated than the mudsync demo, which was built for a Goblins predecessor) and a graphical system that uses assets following the Liberated Pixel Cup style guide (see the Universal LPC Spritesheet for updated assets and the vast collection of compatible assets).

So, Goblins has time travel... great! But that's really for within the live runtime. What happens if we want to save the whole state of the world and its objects and bring it back later? And how can we do it securely, especially when objects might want to claim that the next time they're reconstructed that they have more power and authority than they actually did? (Oh yeah... didn't you know I'm the king, and I have a magic scepter that allows me to banish anything I point it at, and also I have one bajillion pieces of gold in my account? Yes, yes...)

By following the patterns laid out in Safe Serialization Under Mutual Suspicion, it should be possible to serialize, restore, and upgrade graphs of objects and their relationships which are dynamically generated as the program runs. No need to fear about everything falling apart if your game server crashes... just spin it back up!

Okay, so you've built a complicated networked program... but now all these messages are flying around the network and you can't tell what is causing what anymore! Questie solves this with a design highly inspired by the Causeway message-oriented distributed debugger (more: a wonderful screencast, tech report, erights page). Thanks to Goblins' design, we should also be able to add some nice features of being able to snapshot the running state of the program at relevant points to let developers explore the local state of the world the time in question.