I'm assuming what you meant is "the project page doesn't explain those" rather than it doesn't "mention" those.
And it's true that it doesn't give a definition; presumably at this earlier stage, the people most interested in the website are people who are already interested in some way in the federated social web. The ActivityPub spec is linked to though, so it's not hard to find out more info about it.
How about some high level overview of what they're trying to do instead of a spec? Not going to read the spec based on 'you're lazy, go read the spec'.
Hi! I'm the lead author of Spritely here. Totally understand that sentiment, and you're not wrong that it's hugely ambitious.
So, Spritely's approach to vaporware avoidance is to break things into subprojects and show how we're making progress with demos. If some of the subprojects fail, but the others still exist and are useful independently, that's a big win.
Even if that's all that succeeds from Spritely (and I don't think it will), I think that's a useful contribution.
But seeing is believing, and skepticism is well warranted. All I can say is, I hope that in two years we can come back to this post and re-evaluate it and see how far Spritely is along. I hope we can prove ourselves. I'm working very hard to do so.
There's no mailing list... right now just the fediverse and twitter accounts, irc, and the gitlab branches. I would be open to having a mailing list except that I'm aware the kind of maintenance burden involved in keeping them alive, and I have too much work to do on the core. Recommendations?
(Also, I hope we can get to the point where we dogfood Spritely for Spritely communications, but I think that's ~1-1.5 years out from now.)
Disclaimer: Not an expert and haven't run mailing lists before.
I wouldn't necessarily be worried about having the mailing list be open for discussion, irc/gitlab/fediverse covers that pretty well.
That being the case, all the mailing list would need to do would be send the content/links of/to the fediverse posts whenever there's a large enough update to be newsworthy. I just brought it up because that's a way to make sure people can get notifications without having to sign up to new services.
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.
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.
Also even then, I don't expect people to understand just from hearing me explain about it in words. Seeing is believing, and this is why Spritely is taking a "demo-centric" approach. More thoughts on that here: https://dustycloud.org/blog/if-you-cant-tell-people-anything...
Hi! Wow, the website just got up a couple days ago... that was fast for hitting the HN homepage...
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
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.
Spritely Goblins looks so good I'll be pinching it at a later date!
I'd be keen to see what your thoughts are on transactional logs here- you're using snapshots so technically you could do a transaction log, which in turn can be used to help resolve distributed remote call issues eg. if you have 2 nodes and a split-brain scenario you can use the transaction log with a (vector) clock and defined types to resolve the split when connectivity is restored.
Additionally, do you have any thoughts on GC of objects? I'd have thought that Object Capability Security would factor into this.
Hi there! Yes, the transaction log stuff is of interest to me, and ties in with the "Questie" stuff (the one listed as inspired by the causeway debugger). Not quite on the front burner yet, but it'll have to be to make our lives easier.
Goblins already supports distributed (acyclic) GC! And yes ocap security does tie in nicely. In a sense ocaps make this really easy... if you think about an ACL approach the user has to point at the object they have access to and the object has to point back, but since ocaps are based on "having references to objects", in general GC locally can just be the very GC that the native runtime provides. Across runtimes (in the distributed code), distributed GC likewise falls out easier, though the algorithm doesn't know how to handle cycles when Alice on machine A points at Bob on machine B which points at Alice on machine A again. So you have to manually cycle break in those cases, but they're relatively rare.
But that requires special cooperation to traverse the object graph held by the runtime's garbage collector, which we don't have access to in Racket (or most languages) unfortunately. It would really be cool to see that tech revived somewhere though.
which details an RAII + message queue solution for managed memory without GC. The idea there is that provided your message API is well defined, you can determine the queue size in advance, and thus deterministically manage the memory (ie. object lifetime).
I'm mentioning it here, as if capabilities and RPC are added to the mix, you can treat remote objects as part of the memory DAG - RPC calls are just another message on the queue (capabilities here act as a root trace as if you have a message on the queue, you can trace back to the root) and the object can be removed when the queue is zero.
In addition, as per Rust, we should be able to lean on the compiler somewhat, to do some static cycle analysis.
I don't think you can get away from having a cycle checker at high level, but with a transaction log + managed memory + functional code it should make a cycle checker easier to write.
Lastly, I was thinking about the DAAS space - all of this distributed stuff will require authentication (authN) and authorization (authZ).
I think primarily this comes down to IBS (Id Based Signatures) for authN, and then storing encryption secrets to access resources in a distributed hash tree (https://wmcode.nl/dh3/dh3_paper_v0-5.pdf), but any thoughts on how to secure items without POW (proof of work)?
Effectively the DHT is a POS (proof of stake) as you define who owns the resources by attaching an access hash to the secret.
We're not using E, we're strongly inspired by it. It's written in Racket/Scheme because it's a very easy environment to do experimentation with language ideas in. It turns out everything we've built didn't really require language-level ideas, and could be ported to any language that has sane lexical scoping support. And with the CapTP networked layer, we might even be able to achieve interoperability.
In fact, we're in talks with the wonderful folks at Agoric, who are building very similar things in Javascript-land: https://agoric.com/
And we want our two CapTP implementations to be compatible. If we do that, you can have programs written in Scheme/Racket talking to programs written in Javascript just fine.
I'd love to read a discussion about how ActivityPub is too complex, but searches for "AcivityPub overcomplex" and "ActivityPub complex" didn't return anything in the first ~20 results or so. Do you have a pointer to one of the places it is described as overcomplex?
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.
The choice of GPL doesn't seem to be hurting the Linux Kernel. I doubt it'll hurt a package manager either. Plenty of Debian infrastructure software is also GPLv3.
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.)
It's open source, so of course it's 'possible', but if it's difficult to do and another project actually fully supports my use case, documents it, allows questions on IRC and mailing lists with regards to it... the choice for many is obvious then. Last I checked the Linux Kernel was GPLv2 only, and we all (I guess) know the reasons why.
I don't think it's intended as that slang... I think it's probably in the scheme tradition of self-deprecating conspiratorial names... I suspect it's meant to invoke that theme.
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'm amazed how it can be possible not understand that what came up in the author's mind is not the issue at all, and irrelevant.
According to your reasoning, I can name an alarm program "cock", just as long as what was going through my mind at the time was a rooster crowing in the morning. ("Get woken up by cock!") What anyone else chooses to read into it is their problem?
"cock" is not a very good example. Gash, as slang, is nowhere near as often used as "cock". Gash's meaning as "a long, deep cut" is, by far, the most used meaning. Whereas "cock", nowadays, the slang term is pretty much the only used meaning. Peach, rod, purse, knob, sheath, pocket, meat, etc. All these words have alternate slang meanings as well. Should we stop using their original meanings? Like I said in another comment, language is all about context. I've only ever heard 'gash' used as slang in the U.K. I would imagine a very large chunk of the English speaking population only know the non-slang meaning.
Legend has it that Gérard Huet, who named Coq, enjoys double entendre and chose the name deliberately, just like he did with the Zipper data structure. So this might not be a great example of something that accidentally has a double meaning.
Apparently some British researchers were working on a theorem prover named Bit, which in French sounds like "bitte" (slang for penis). So the French researchers who worked on Coq cheekily chose a French word with a double-entendre meaning in English.
But all these anecdotes counteract what Wikipedia says, which is that Coq was named for one of its authors, Thierry Coquand, and for his "calculus of constructions" (CoC).
>But all these anecdotes counteract what Wikipedia says, which is that Coq was named for one of its authors, Thierry Coquand, and for his "calculus of constructions" (CoC).
It being named after Coquand is unsourced and even states something that is outright wrong (Coquand is not Coq's "principal author", the best fit would be Huet and Christine Paulin, but even then it was developed by a team, they just lead it. Source: Coq's history page).
> I'm amazed how it can be possible not understand that what came up in the author's mind is not the issue at all, and irrelevant.
Oh my, then you better not ever venture into the humanities! At least in musicology they spent the past 3 decades wresting free from the idea that evidence of the author's intentions are the only relevant thing.
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...
- 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.
Hello! Thanks so much for the reply. This is exactly why I post critiques. I want to spur conversation.
Everything I'm reading in your comment and in the links you shared, I agree with. I think the main difference is in our choice of tools.
For the network mapping (for trust and petnames), I believe that a graph structure is required. Having this at a foundational layer is important for scalability and mathematical simplicity imo.
Other than that, I think we agree on offline-first and multi-casting being requirements. And bonus points for keypair management through shamir's secret sharing and multi-device key management.
Can I contact/keep up with you directly somewhere to continue the conversation?
What's your AP username? I would like to follow you to keep up with these developments and maybe pitch in where I can. I did a quick googling but didn't find anything.
Ah, Mark Miller on promises! I am building a system (Spritely Goblins) which is very inspired by another system largely designed by MarkM, the "E" programming language. I'm borrowing most of the way promises work in E in Goblins. For those that don't know, the idea of promises in Javascript largely got ported from E, though not entirely (there are some things nicer about E's promises than Javascript's... promise pipelining is one clear one, and the "when" clause is much nicer than Javascript's .then() sausage-chains).
However I didn't realize that MarkM's work with promises predated E, that it started in his work on Xanadu... that makes sense.
- "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).
We met at Racket con this last year (and grabbed dinner briefly). I love your passion for open projects and think about that, especially as I make my own plans!
I especially love your passion for the reality of funding for open projects, and I'm excited to see what comes of your labors.
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. ;)
And it's true that it doesn't give a definition; presumably at this earlier stage, the people most interested in the website are people who are already interested in some way in the federated social web. The ActivityPub spec is linked to though, so it's not hard to find out more info about it.