2,351 karma · joined August 30, 2011
Hi! Spritely's main author here. Spritely is taking on quite a few things, so it's understandable that it might not be completely clear what from the tagline.
Here's the short version: we'd like to bring better security, privacy, and rich interactions to the federated social web. I was one of the co-authors of the ActivityPub standard so I have some strong opinions about what it's capable of that isn't happening yet.
If you want a friendly, semi-visual overview, here's a video I just recorded for the ActivityPub conference: https://conf.tube/videos/watch/18aa2f92-36cc-4424-9a4f-6f2de...
It goes over (most of) the layers in a fairly friendly way.
Within all the subprojects listed, the most ambitious is the Fantasary one, which is distributed virtual worlds. Not as out there as it sounds, such a thing was built in the mid/late 90s: https://www.youtube.com/watch?v=KNiePoNiyvE
But in the dot-com crash, went up in flames. However many of the ideas were carried forward by the object capability community, particularly the E language, on which Spritely Goblins is heavily influenced: http://www.erights.org/
The distributed games goal then becomes a driver for the other components, so even if that fails we should hopefully still get cool stuff. Spritely Goblins, the foundational layer, already exists and has support for such features as time travel debugging: https://dustycloud.org/blog/goblins-time-travel-micropreview...
and distributed networked programming, safe to run in a hostile network... here's a chat program where the "protocol" authenticates the users joining the channel and also that the messages came from them, with the chatroom and user "protocol" both written in 250 lines of code combined... and without being planned at all for networked interaction, it just worked over the network... here's a gif of it working over Tor Onion Services: https://dustycloud.org/misc/goblins-chat-captp-onion-service...
No code was added to the "protocol" to expect network interactions; Goblins' CapTP (Capability Transport Protocol) took care of that for us.
Already that should sound pretty cool, but that's just the foundation for the system. Look at the other subprojects to see where we're going from there.
Happy to answer questions if anyone has them!
But the work has actually been happening for a couple of years, and the foundational layer, Spritely Goblins, is already something you can use: https://docs.racket-lang.org/goblins/index.html
I think people don't tend to get very excited until they see the time travel demo, and then they say "whoa, something cool is going on here" https://dustycloud.org/blog/goblins-time-travel-micropreview...
But that's not really the most interesting part of Spritely Goblins... the safe to run in a mutually suspicious network distributed programming environment is.
Some background: I was one of the co-authors/co-editors of the ActivityPub social network standard... you might know it because it's the protocol used by Mastodon, but it's also used by Peertube, NextCloud, Write Freely, Funkwhale, Pixelfed, etc. I actually got involved in standardization because we needed it for the previous project I worked on, MediaGoblin. After standardization of ActivityPub ended, it turned out that a number of ActivityPub-using applications such as Peertube and Pixelfed and Funkwhale were using the protocol we worked on standardizing to do the kinds of things we meant to work on in MediaGoblin. So I asked myself, given the finite amount of time I have on this planet, what's the best use of my time? At this point I thought (and with a lot of feedback and phone calls with close friends): I should work on advancing the things that the federated social network can't do. And there are quite a few of those because ActivityPub left some gaps in the spec, especially around authentication and authorization, but also because people aren't building as rich of experiences as I think are interesting and possible yet... they're mostly mimicing contemporary social networks.
So you can see in that long list of things on the Spritely website that one of them is Fantasary, which is the goal of bringing distributed virtual worlds to the fediverse. That may sound like a hyper-ambitious and also kind of strange goal, but consider that modern social networks are really degenerate versions of massively multiplayer games; you can chat in both, but most social networks don't have the sense of space and rich interaction that games do. But I also want to make more obscure peer-to-peer technologies available and in the hands of users without the usual "Oh no those are only for the bad people on the internet"... normalizing things can help. Those of us old enough remember when demanding https was similarly brought up with the "well, that's only for people who have something to hide". A use case of e-commerce changed that. Well, I want another use case... but one that involves fun. Hence the distributed game stuff. We can see how motivating building worlds together is by the success of minecraft.
But what if the Fantasary component fails? It's the most ambitious piece! That's actually okay, because it's really a driver for all the other layers. Distributed programming that's safe to run in a hostile network, portable encrypted storage, the ability to safely run untrusted code... all of these are useful things, and useful things to bring to users generally, even if the game approach fails.
But actually all of these layers are quite well researched and possible. Part of the reasons that Spritely development happened before two years before the launch of the Spritely website is because when we ran MediaGoblin, we opened up the project and within a couple of weeks had dozens of developers... but that was quite feasible to accomodate because MediaGoblin was a fairly "traditional" web application, easy enough to point to how it works by other similar web applications. Spritely is treading a lot of what appears to be "new ground" to most people, so I had to figure out how it works enough, and lay enough of the foundation, before I was comfortable making a public image for it and asking people to start looking at it. But with the last release of Goblins with the beginnings of distributed network programming and with a fairly reasonable tutorial, that's starting to change.
But I said "new ground" to most people, but few of these are actually new ideas. Most of them are old, well researched ideas, from a somewhat obscure (but becoming quickly less so) branch of computer science called "object capability security". I've been very fortunate that the object capability security community has been willing to take the time to walk me through how many of these concepts work... Spritely wouldn't be possible without their help.
If you want to hear more, the video embedded on the site is a good overview, but here's a direct link: https://conf.tube/videos/watch/18aa2f92-36cc-4424-9a4f-6f2de...
Anyway, happy to answer questions if anyone has any. And feel free to join our irc channel... we're #spritely on irc.freenode.net!
The FSF is GNU's sponsor, and provides some infrastructure, but generally hasn't done too much in terms of funding the project. However other funding has happened in terms of NLNet, Outreachy, GSoC, and some stuff with the Guix HPC project. But far and away the majority of contributions are from unpaid contributors.
At any rate, the choice to go "have a pure base" is the right one IMO: it's nice to have a system where I know I have the right to use/modify/distribute changes to the entire thing. It's easier to start with that pure base and add impurities if you need them (eg if your hardware requires blobs to operate it) than the reverse.
That said I think it would be helpful if there was a place to direct users who need to figure out how to install such blobs, even though I agree that the official mailing lists and project repository should not be it. (I am running a blobbed kernel on my current machine because I have to, but I previously was able to run with the linux-libre kernel Guix ships with. It's definitely possible to do if you need to, just not well documented.)
Not to mention that "bash" sounds like a concussive injury; "gash" sounds like a slicing injury. So follows that theme also.
I would be very surprised if genitalia slang came up in the author's mind as a choice of names but I guess I don't know them.
I think you'll find it agrees with your assessments. DNS and SSL Certificate Authorities centralize an otherwise sensible decentralized system.
It's out of date because work has continued. Here's some hints as to how we can improve the situation:
- Decrease importance of server you're on by allowing easy account migration. One easy way to do this is to use mutable data to represent your activitypub profile in a content-addressed store... you can look at mutable links in IPFS as an example (the work that we're doing on Datashards is also relevant). (ActivityPub actually does support other URI types that are not https so this is no problem...) Don't like the server you're on? Update your actor profile to point its inbox URI at another place.
- Support hosting over more p2p, easily self-hostable, NAT-punching and secure systems where you know you have a secure connection because the name of the server is actually the fingerprint of the key. That's actually what tor .onion servers and I2P servers are. There's no reason you can't run ActivityPub over such servers, and some people do, but it isn't widely supported because...
- ... because of the way we've chosen to do names. The right answer isn't webfinger (which isn't in the ActivityPub spec but is what's popularly deployed), it's petnames: https://github.com/cwebber/rebooting-the-web-of-trust-spring...
- And now you need a way to handle anti-abuse in a system that doesn't assume that domain names and instances are all too important. OcapPub outlines some of that (sadly unfinished, but the core ideas are there) https://gitlab.com/spritely/ocappub/blob/master/README.org
- On top of all that, maybe add store and forward messaging to support nodes being offline. This can be done and we have plans but I need to write them in a more visible place.
So in short, as one of the main authors of the biggest fediverse specs out there, not only do I agree, work is happening.
However I didn't realize that MarkM's work with promises predated E, that it started in his work on Xanadu... that makes sense.
I appreciate that and am thrilled when I hear that enthusiasm rubs off. I promise all this game stuff amounts to something interesting in relationship to the federated social web, even if it isn't obvious yet from here. ;)
Author here, happy to answer any questions about how this was made, though I'll answer a few things up front:
- It's made in Racket, and as for why there's a whole section about that if you scroll down on on: https://dustycloud.org/blog/terminal-phase-prototype/
- I showed a playthrough (pre-1.0) as well as how to add new levels and enemies on a live stream I did last week: https://www.youtube.com/watch?v=wxt2dqqulQc
- "Why?" This is actually a test program for some stuff I'm building for the future of the federated social web (if you are familiar with ActivityPub, I'm one of the authors of that), an ocap-actor-model-framework called Spritely Goblins. More on Spritely here: http://dustycloud.org/blog/spritely/
- (Shameless shill) If you think this is cool, this was actually funded by people who donate to my Patreon account and was a reward. If you donate, you can show up in the credits of the game: https://www.patreon.com/cwebber
BTW a newer version of Racket is needed, at least 7.3 (maybe 7.2 is fine). If you play the game, let me know! I'll be adding more stuff soon, including powerups, more levels, a boss, and better balance for level 2 (which is probably a bit too brutal for a second level).
I tried being moderately conservative for the moment because I'm not sure which terminals support what! (Admittedly the recent addition of starfields in git master stepped away from that a little)
Yes, the standardization process was a difficult one. Standards efforts often are, and social web ones especially. Nonetheless I think we did a good job.
The purpose of those posts is to ask people to stop fighting each other and try to work together; it feels highly ironic for you to quote them to increase division.
- Yes, there are some quirks in the standard library, but overall most of it seems very well designed. Having spent a bunch of time in Python, which also has a standard library with I'd argue even more quirks. But most Racket libraries seem very carefully thought out IME; I'm not sure that something this old can not have some weird oddities though. - We used DrRacket to teach a class to students who had never programmed before. What's amazing is that a) the students picked it up quickly and immediately... what other lisp can claim having something like that? and b) it's the only editor that I myself am happy to use other than Emacs. That's an interesting and unusual overlap, and deserves a pat on the back.
Yes, Racket has its quirks, but what doesn't? It's still an extraordinary project, community, development environment IMO.
I think there are quite a few of those people... maybe that gives some hope for contributions
You're not wrong. And neither is the parent post! MediaGoblin is in "unofficial retirement", but that's because we made progress unexpectedly in other ways, which is good, but not where we realized we were going. Allow me to lay out what happened and what the history is here.
About four (or was it five?) years ago, MediaGoblin was still a very active project and a lot of it worked, but we still didn't have working federation support. At the time we were looking at a lot of different protocols and it wasn't clear which approach was the right one, but Evan Prodromou had written up the Pump API document: https://github.com/pump-io/pump.io/blob/master/API.md
Even though pump.io didn't have the highest uptake, it seemed to have the cleanest design and addressed many issues that OStatus had. Evan did StatusNet which is what's also now called GNU Social, and has done more work to advance the federated social web than anyone else, and given how clean the design looked and that I trusted Evan, I thought this was the right approach. So we used the funds from the second crowdfunding campaign we ran and hired Jessica Tallon, who had written PyPump (and understood the practical details better than me at the time, I was learning as I went), to do the implementation. We got as far as getting MediaGoblin and Pump.io to talk to each other and pump.io clients to even work on MediaGoblin.
But there was still a problem... nobody else was using the Pump API but our two projects, and at this point all these different projects on the fediverse were speaking different protocols (and sometimes not even compatibly speaking the same protocol)... what I would call in talks as a "fractured federation". I heard Evan Prodromou mention he was going to be co-chairing the W3C Social Working Group and I asked that Jessica and I could participate, and we were brought in as what are called "invited experts". At this point Erin Shepherd had transformed the Pump API document into a prototype W3C spec document called "ActivityPump" and that was the direction Jessica and I got pulled in to.
There were a lot of smart people in the group, and my assumption was, they probably all knew what they were doing and I told Jessica "we can just show up for an hour a week to make sure they're on track and doing what we need and then we can focus on MediaGoblin". I didn't know the phrase "revolutions are run by the people who show up" but I certainly do now... Jessica and I got drawn in as co-editors of the ActivityPub standard. We had raised enough money from the second crowdfunding campaign to pay Jessica for a full year (I didn't take any money from that campaign) but we stretched it out to two years by Jessica and I contracting for Open Tech Strategies part time (great people, btw). This was helpful because when one of us was working on standards stuff, the other person could do some work on MediaGoblin as a project, and there was a lot to do.
But as time went on and deadlines became more urgent, standardizing ActivityPub grew more and more in time consumed. Eventually it became my full time job; I would work 40-50 hours a week on ActivityPub and do 10-20 hours of contracting on the side to pay the bills. It was clear we were doing something important and there was a real opportunity.
But ActivityPub grew to three and a half years of standardization work and as I said, we only could stretch out paying Jessica for two, so she had to find paying work and it wasn't possible for us to split our time to manage both. In the meanwhile, even though all this stuff was happening for MediaGoblin, I found less and less time to work on the project. Even worse, Gitorious (which we had previously been hosted on) went down, and we were unsure where to move to. A community member volunteered to do the work to move us to Savannah and we took it. MediaGoblin wasn't using Gitorious's issues/merge request tools anyway; the way people would make contributions is make a new git branch, publish it anywhere, and then link that branch on the issue tracker where we'd do the code review and then eventually we'd merge it in. In that sense we were already using git in a more distributed manner (the way that git was intended I'd even argue)... but actually I do think we lost something in the move from Gitorious to Savannah. What we lost is that many people didn't know where to host branches, and Gitorious (along with many other such services) tend to offer a one-click easy process to fork, where you don't have to learn or debate over how/where to host things if you don't already have a preference. Our server infrastructure also languished... we previously had some volunteers helping with the infrastructure but they ran low on time, there was a server migration that went badly (it's still in a bad state tbh), spam filled up our wiki and trac instances, and it was all a huge headache that I didn't really have time to deal with. And I wasn't there to help steward the project the way I used to... I did appoint a co-maintainer (Breton) who did great work but I guess I did help drive a lot of the energy for the project and so when I stopped working on it actively, the community languished. We went from dozens of active contributors to practically none over the course of ActivityPub's standardization.
It wasn't clear that it was worth it; towards the end of ActivityPub's standrdization it looked like we wouldn't even make it and I thought I wasted years of my life. Then Mastodon picked it up, then Peertube, then etc etc and we suddenly had dozens of ActivityPub implementations. It turns out it was worth it, and finally we had a fediverse that did talk to each other. It turned out MediaGoblin did make a large contribution to the federated social web, but it wasn't in the way I expected... it was a driving force, rather than the project people ran.
Still, afterwards I came back (and with a more strong sense of how finite and fragile time is than ever) and I had to debate: should I pick up and run full swing with MediaGoblin again? The project could pick up and with effort, merge the languishing federation branch, I could try to drum up excitement in the community again, we might even make it.
But the webdev world shifted and so did I. IPFS and Webtorrent didn't exist when MediaGoblin started, and Peertube did the smart thing of integrating those into their project and it felt like they handled our ideas better than we did there. There were also all these other projects (Pixelfed, Funkwhale) which, while not delivering all the media types in one package (why the heck not? I still don't understand that) which seemed to be doing the same thing we were and actually were already federating... with the protocol we built for our own needs with MediaGoblin no less! And web applications aren't typically built as request-response type systems any more (and I for one was tired of it and had become disillusioned for my interest/belief in for Python being a great asynchronous language), and I just didn't feel excited about the codebase anymore. What to do?
I had another idea, and I called up several of my closest free software friends to make sure that the path I was suggesting wasn't an awful one. The main success I have had turned out to not be in the applications I built but in the way I showed how to grow distributed systems, and I now understand even the deficiencies (but how we can improve building on the base we have) on the current federated social web. So that's where Spritely came from, and why I'm building it as a series of demos (more here:) https://dustycloud.org/blog/spritely/ (first documented demo here:) https://gitlab.com/spritely/golem/blob/master/README.org
So what lead to MediaGoblin's "unofficial retirement"? I think that it's both true that a) the standardization effort of ActivityPub, while done for MediaGoblin, accidentally lead to a loss of energy in MediaGoblin's community b) there was a falloff in code/infrastructure hosting and other challenges related to that c) other projects picked up on what MediaGoblin was doing and arguably did it better, using ActivityPub even, and finally d) I still believe there are serious problems and deficiencies in the current federated social web that are addressable, and so I started the Spritely project to document and demonstrate a path forward there.
You could focus on just any one of those, but I think the story is clearest when it's told all together.
Anyway, it's free software! If someone is interested in revitalizing the project and community, I'm still interested in that happening.. maybe reach out to me and we can figure out how to continue. I'm easily found: https://dustycloud.org/contact/
- Using it with salt and water makes a kind of chicken broth'y flavor. - Butter or margerine on toast, then sprinkle nutritional yeast on top. Doesn't sound like it'll be good but a friend introduced this to me and it's one of my favorite snacks. - Add to tomato sauce for a "meat drippings" like flavor. For an easy and cheap spaghetti bolognese use TVP, nutritional yeast, a dash of tarmari, and your usual tomatoes and oregano and basil. - Of course, a lot of people use it as fake cheese... you can make a "nacho cheese" type flavor out of it easily
Tons more uses.
But... you can also get it online for fairly cheap! Here's a pound for less then 12 dollars. IME a pound goes a long way. https://www.amazon.com/Frontier-Co-op-Nutritional-Yeast-Flak...
There's a solution in delimited continuations, however delimited continuations seem to only be used and understood in the Scheme community (are they used anywhere else?). Delimited continuations allow you to suspend your code to a "prompt" lower in the stack at that point... and it doesn't matter if you have non-"async" code in between.
It'll be nice when they make their way to other more mainstream languages.
Currently ActivityPub servers in practice use HTTP Signatures and Linked Data Signatures, so there's a certain amount of proof of the origin of messages there. But in moving towards a much more peer to peer system, we can do even better by stripping out SSL Certificate Authorities and DNS altogether. The paper linked above discusses one path to accomplishing that in ActivityPub using DIDs. Hope that's interesting to you!
Has the internet really regressed so much that developers would also make the argument that it's a better idea to have one or two email providers, for instance, than have it be a distributed system? What about many wordpress instances, etc?
However! It will be possible for ActivityPub applications to move in the direction of being more distributed systems... in fact I wrote a paper on this which I will be presenting at Rebooting Web of Trust in October: https://gitlab.com/dustyweb/talks/blob/master/activitypub/rw...
There's a lot of ideas in that paper, but the one that applies to a nomadic identity is Decentralized Identifiers support, or DIDs: https://w3c-ccg.github.io/did-spec/
DIDs are being worked on by the W3C Credentials Community Group (which I am also a part of) and will permit having an identity that is "self-soverign". How I imagine this would work in an application like Mastodon, if Mastodon decides to include support for it in the future, is that you would register a DID for yourself and then go to your profile page and associate that DID with your user. You'd then have identity that isn't tied to one specific node... indeed, in such a direction we'd begin to blur the line between the federated client-server web application model and peer to peer networks.
That's a ways off though. For now I think ActivityPub brings a lot of benefits to Mastodon (though I'm biased obviously). Still lots of exciting future ahead though!