Archives

Tags

Posts with tag "foss"

Spritely Goblins v0.7 released!

By Christopher Lemmer Webber on Sun 13 September 2020

I'm delighted to say that Spritely Goblins v0.7 has been released! This is the first release featuring CapTP support (ie, "capability-secure distributed/networked programming support"), which is a huge milestone for the project!

Okay, caveat... there are still some things missing from the CapTP stuff so far; you can only set up a bidirectional connection between two machines, and can't "introduce" capabilities to other machines on the network. Also setting up connections is an extremely manual process. Both of those should be improved in the next release.

But still! Goblins can now be used to easily write distributed programs! And Goblins' CapTP code even includes such wild features as distributed garbage collection!

As an example (also mentioned in a recent blogpost), I recently wrote a short chat program demo. Both the client and server "protocol" code were less than 250 lines of code, despite having such features as authenticating users during subscription to the chatroom and verifying that messages claimed by the chatroom came from the users it said it did. (The GUI code, by contrast, was a little less than 300 lines.) I wrote this up without writing any network code at all and then tested hooking together two clients over Tor Onion Services using Goblins' CapTP support, and it Just Worked (TM):

Goblins chat GUI demo

What's interesting here is that not a single line of code was added to the backend or GUI to accomodate networking; the host and guest modules merely imported the backend and GUI files completely unchanged and did the network wiring there. Yes, that's what it sounds like: in Goblins you can write distributed asynchronous programs

This is the really significant part of Goblins that's starting to become apparent, and it's all thanks to the brilliant design of CapTP. Goblins continues to stand on the shoulders of giants; thank you to everyone in the ocap community, but especially in this case Michael FIG, Mark S. Miller, Kevin Reid, and Baldur Jóhannsson, all of whom answered an enormous amount of questions (some of them very silly) about CapTP.

There are more people to thank too (too many to list here), and you can see some of them in this monster thread on the captp mailing list which started on May 18th (!!!) as I went through my journey of trying to understand and eventually implement CapTP. I actually started preparing a few weeks before which really means that this journey took me about four and a half months to understand and implement. As it turns out, CapTP is a surprisingly simple protocol protocol in its coneptualization once you understand what it's doing (though implementing it is a bit more complex). I do hope to try to build a guide for others to understand and implement on their own systems... but that will probably wait until Goblins is ported to another language (due to the realative simplicity of the task due to the language similarities, the current plan is to port to Guile next).

Anyway. This is a big deal, a truly exciting moment for goblinkind. If you're excited yourself, maybe join the #spritely channel on irc.freenode.net.

OH! And also, I can't believe I nearly forgot to say this, but if you want to hear more about Spritely in general (not just Goblins), we just released a Spritely-centric episode of FOSS and Crafts. Maybe take a listen!

If you can't tell people anything, can you show them?

By Christopher Lemmer Webber on Sat 29 August 2020

The other day I made a sadpost on the fediverse that said: "simultaneously regularly feel like people don't take the directions I'm trying to push seriously enough and that I'm not worth taking seriously". (Similarly, I've also joked that "imposter syndrome and a Cassandra complex are a hell of a combo" before.) I got a number of replies from people, both publicly and privately, and the general summary of most of them are, "We do care! The stuff you're working on seems really cool and valuable! I'll admit that I don't really know what it is you're talking about but it sounds important!" (Okay, and I just re-read, and it was only a portion of it that even said the latter part, but of course, what do I emphasize in my brain?) That was nice to hear that people care and are enthusiastic, and I did feel much better, but it did also kind of feel like confirmation that I'm not getting through to people completely either.

But then jfred made an interesting reply:

Yeah, that feels familiar. Impostor syndrome hits hard. You're definitely worth taking seriously though, and the projects you're working on are the most exciting ones I've been following.

As for people not taking the directions you're pushing seriously... I've felt the same at work, and I think part of it is that there's only so much one person can do. But also part of it is: http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/

...it's hard to get ideas across to someone until they can interact with it themselves

So first of all, what a nice post! Second of all, it's kind of funny that jfred replied with this because out of everyone, jfred is one of the people who's picked up and understood what's happening in Spritely Goblins in particular the most, often running or creating demos of things on top of it using things I haven't even documented yet (so definitely not a person I would say isn't taking me seriously or getting what the work is doing).

But third, that link to Habitat Chronicles is right on point for a few reasons: first of all, Spritely is hugely influenced by the various generations of Habitat, from the original first-ever-graphical-virtual-worlds Habitat (premiering on the Commodore 64 in the mid 1980s, of all things!) to Electric Communities Habitat, especially because that's where the E programming language came from, which I think it's safe to say has had a bigger influence on Spritely Goblins than anything (except maybe this paper by Jonathan Rees, which is the first time I realized that "oh, object capability security is just normal programming flow"). But also, that blogpost in particular was so perfect about this subject: You can't tell people anything...!

In summary, the blogpost isn't saying that people aren't foolishly incapable of understanding things, but that people in general don't understand well by "being explained to". What helps people understand is experiences:

Eventually people can be educated, but what you have to do is find a way give them the experience, to put them in the situation. Sometimes this can only happen by making real the thing you are describing, but sometimes by dint of clever artifice you can simulate it.

This really congealed for me and helped me feel justified in an approach I've been taking in the Spritely project. In general, up until now I've spent most of my time between two states: coding the backend super-engineering stuff, and coding demos on top of it. You might in the meanwhile see me post technobabble onto my fediverse or birdsite accounts, but I'm not in general trying too hard to write about the structurally interesting things going on until it comes time to write documentation (whether it be for Goblins, or the immutable storage and mutable storage writeups). But in general, the way that I'm convinced people will get it is not by talk but by first, demonstration, and second, use.

Aside from the few people that have picked up and played with Goblins yet, I don't think I've hit a sufficient amount of "use" yet in Spritely. That's ok, I'm not at that stage yet, and when I am, it'll be fairly clear. (ETA: one year from now.) So let's talk about demonstration.

The first demo I wrote was the Golem demo, that showed roughly that distributed but encrypted storage could be applied to the fediverse. Cute and cool, and that turned the heads of a few fediverse implementers.

But let's face it, the best demo I've done yet was the Terminal Phase time travel demo. And it didn't hurt that it had a cool looking animated GIF to go with it:

Time travel in Spritely Goblins shown through Terminal Phase

Prior to this demo, people would ask me, "What's this Goblins thing?" And I'd try to say a number of things to them... "oh, its a distributed, transactional, quasi-functional distributed programming system safe to run in mutually suspicious networks that follows object capability security and the classic actor model in the style of the E programming language but written in Scheme!" And I'd watch as their eyes glaze over because why wouldn't their eyes glaze over after a statement like that, and then I'd try to explain the individual pieces but I could tell that the person would be losing interest by then and why wouldn't they lose interest but even realizing that I'd kind of feel despair settling in...

But when you show them a pew pew space lasers game and oh wow why is there time travel, how did you add time travel, is it using functional reactive programming or something? (Usually FRP systems are the only other ones where people have seen these kinds of time travel demos.) And I'd say nope! It doesn't require that. Mostly it looks like writing just straightahead code but you get this kind of thing for free. And the person would say, wow! Sounds really cool! How much work does it take to add the time travel into the game? And I just say: no extra work at all. I wrote the whole game without testing anything about time travel or even thinking about it, then later I just threw a few extra lines to write the UI to expose the time travel part and it just worked. And that's when I see peoples' heads explode with wonder and the connections start to be made about what Goblins might be able to do.

But of course, that's only a partial connection for two reasons. One is that the time travel demo above only shows off a small, minute part of the features of Goblins. And actually, the least interesting of them! It doesn't show off the distributed programming or asynchronous programming parts, it doesn't show off the cool object capability security that's safe to run in mutually suspicious networks. But still: it gave a taste that something cool is happening here. Maybe Chris hasn't just been blowing a bunch of time since finishing the ActivityPub standardization process about two and a half years ago. (Yikes, two and a half years ago!?!)

To complete the rest of that demonstration of the other things in the system requires a different kind of demo. Terminal Phase was a demo to show off the synchronous half of Goblins, but where Goblins really shines is in the asynchronous, distributed programming stuff. That's not ready to show off yet, but I'll give you the first taste of what's in progress:

Goblins chat GUI demo

(Actually a bit more has progressed since I've recorded that GIF, multiple chatrooms and etc, but not really worth bothering to show off quite yet.)

Hmm, that's not really all that thrilling. A chatroom that looks about the same level of featureful, maybe less, than IRC? Well, it could be more exciting if you hear that the full chat protocol implementation is only about 250 lines of code, including authenticating users and posts by users. That's smaller even than its corresponding GUI code, which is less than 300 lines of code. So the exciting thing there is how much heavy lifting Goblins takes care of for you.

But that's hardly razzle-dazzle exciting. In order for me to hint at the rest of what's happening here, we need to put out an asynchronous programming demo that's as or more interesting than the time travel demo. And I expect to do that. I hope soon enough to show off stuff that will make people go, "Oh, what's going on here?"

But even that doesn't complete the connection for people, because showing is one thing but to complete the loop, we need people to use things. We need to get this stuff in the hands of users to play with and experiment themselves. I have plans to do that... and not only that, make this stuff not intimidating for newcomers. When Spritely guides everyday people towards extending Spritely from inside of Spritely as it runs, that's when it'll really click.

And once it clicks sufficiently, it'll no longer become exciting, because people will just come to expect it. A good example of that comes from the aforementioned You can't tell people anything article:

Years ago, before Lucasfilm, I worked for Project Xanadu (the original hypertext project, way before this newfangled World Wide Web thing). One of the things I did was travel around the country trying to evangelize the idea of hypertext. People loved it, but nobody got it. Nobody. We provided lots of explanation. We had pictures. We had scenarios, little stories that told what it would be like. People would ask astonishing questions, like “who’s going to pay to make all those links?” or “why would anyone want to put documents online?” Alas, many things really must be experienced to be understood. We didn’t have much of an experience to deliver to them though — after all, the whole point of all this evangelizing was to get people to give us money to pay for developing the software in the first place! But someone who’s spent even 10 minutes using the Web would never think to ask some of the questions we got asked.

Eventually, if we succeed, the ideas in Spritely will no longer seem exciting... because people will have internalized and come to expect them. Just like hyperlinks on the web today.

But to get there, in the meanwhile, we have to get people interested. To become so successful as to be mundane, we have to first be razzle-dazzle exciting. And to that end, that's why I take the demo approach to Spritely. Because it's hard to tell someone something... but showing them, that's another matter.

PS: It's also not true that people don't get what I'm doing, and that's even been reflected materially. I've been lucky to be supported over the last few years from a combination of a grant from Samsung's Stack Zero and one from NLNet, not to mention quite a few donors on Patreon. I do recognize and appreciate that people are supporting me. In some ways receiving this support makes me feel more seriously about the need to demonstrate and prove that what I'm doing is real. I hope I am doing and will continue to do a sufficient job, and hope that the upcoming demos contribute to that more materially!

PPS: If, in the meanwhile, you're already excited, check out the Goblins documentation. The most exciting stuff is coming in the next major release (which will be out soon), which is when the distributed programming tools will be made available to users of the system for the first time. But if you want to get a head start, the code you'll be writing will mostly work the same between the distributed and non-distributed (as in, distributed across computers/processes) asynchronous stuff, so if you start reading the docs today, most of your code will already just work on the new stuff once released. And if you do start playing around, maybe drop by the #spritely channel on freenode and say hello!

Departing Libre Lounge

By Christopher Lemmer Webber on Wed 13 May 2020

Over the last year and a half I've had a good time presenting on Libre Lounge with my co-host Serge Wroclawski. I'm very proud of the topics we've decided to cover, of which there are quite a few good ones in the archive, and the audience the show has had is just the best.

However, I've decided to depart the show... Serge and I continue to be friends (and are still working on a number of projects together, such as Datashards and the recently announced grant), but in terms of the podcast I think we'd like to take things in different creative directions.

This is probably not the end of me doing podcasting, but if I start something up again it'll be a bit different in its structure... and you can be sure you'll hear about it here and on my fediverse account and over at the birdsite.

In the meanwhile, I look forward to continuing to tuning into Libre Lounge, but as a listener.

Thanks for all the support, Libre Loungers!

Spritely's NLNet grant: Interface Discovery for Distributed Systems

By Christopher Lemmer Webber on Wed 13 May 2020

I've been putting off making this blogpost for a while because I kept thinking, "I should wait to do it until I finish making some sort of website for Spritely and make a blogpost there!" Which, in a sense is a completely reasonable thought because right now Spritely's only "website" is a loose collection of repositories, but I'd like something that provides a greater narrative for what Spritely is trying to accomplish. But that also kind of feels like a distraction (or maybe I should just make a very minimal website) when there's something important to announce... so I'm just doing it here (where I've been making all the other Spritely posts so far anyway).

Spritely is an NLnet (in conjunction with the European Commision / Next Generation Internet initative) grant recipient! Specifically, we have received a grant for "Interface Discovery for Distributed Systems"! I'll be implementing the work alongside Serge Wroclawski.

There are two interesting sub-phrases there: "Interface Discovery" and "Distributed Systems". Regarding "distributed systems", we should really say "mutually suspicious open-world distributed systems". Those extra words change some of the requirements; we have to assume we'll be told about things we don't understand, and we have to assume that many objects we interact with may be opaque to us... they might lie about what kind of thing they are.

Choosing how to name interfaces then directly ties into something I wrote about here more recently, namely content addressed vocabulary.

I wrote more ideas and details about the interfaces ideas email to cap-talk so you can read more there if you like... but I think more details about the interfaces thoughts than that can wait until we publish a report about it (and publishing a report is baked into the grant).

The other interesting bit though is the "distributed" aspect; in order to handle distributed computation and object interaction, we need to correctly design our protocols. Thankfully there is a lot of good prior art to work from, usually some variant of "CapTP" (Capability Transport Protocol), as implemented in its original form by E, taking on a bit of a different form in the Waterken project, adapted in Cap'N Proto, as well as with the new work happening over at Agoric. Each of these variants of the core CapTP ideas have tried to tackle some different use cases, and Goblins has its own needs to be covered. Is there a possibility of convergence? Possibly... I am trying to understand the work of and communicate with the folks over at Agoric but I think it's a bit too early to be conclusive about anything. Regardless, it'll be a major milestone once Spritely Goblins is able to actually live up to its promise of distributed computation, and work on this is basically the next step to proceed on.

When I first announced Spritely about a year and a half ago I included a section that said "Who's going to pay for all this?" to which I then said, "I don't really have a funding plan, so I guess this is kind of a non-answer. However, I do have a Patreon account you could donate to." To be honest, I was fairly nervous about it... so I want to express my sincere and direct appreciation to NLnet alongside the European Commission / Next Generation Internet Initiative, along with Samsung Stack Zero, and all the folks donating on Patreon and Liberapay. With all the above, and especially the new grant from NLnet, I should have enough funding to continue working on Spritely through a large portion of 2021. I am determined to make good on the support I've received, and am looking forward to put out more interesting demonstrations of this technology over the next few months.

What should fit in a FOSS license?

By Christopher Lemmer Webber on Mon 09 March 2020

Originally sent in an email to the OSI license-discuss mailing list.

What terms belong in a free and open source software license? There has been a lot of debate about this lately, especially as many of us are interested in expanding the role we see that we play in terms of user freedom issues. I am amongst those people that believe that FOSS is a movement thats importance is best understood not on its own, but on the effects that it (or the lack of it) has on society. A couple of years ago, a friend and I recorded an episode about viewing software freedom within the realm of human rights; I still believe that, and strongly.

I also believe there are other critical issues that FOSS has a role to play in: diversity issues (both within our own movement and empowering people in their everyday lives) are one, environmental issues (the intersection of our movement with the right-to-repair movement is a good example) are another. I also agree that the trend towards "cloud computing" companies which can more or less entrap users in their services is a major concern, as are privacy concerns.

Given all the above, what should we do? What kinds of terms belong in FOSS licenses, especially given all our goals above?

First, I would like to say that I think that many people in the FOSS world, for good reason, spend a lot of time thinking about licenses. This is good, and impressive; few other communities have as much legal literacy distributed even amongst their non-lawyer population as ours. And there's no doubt that FOSS licenses play a critical role... let's acknowledge from the outset that a conventionally proprietary license has a damning effect on the agency of users.

However, I also believe that user freedom can only be achieved via a multi-layered approach. We cannot provide privacy by merely adding privacy-requirements terms to a license, for instance; encryption is key to our success. I am also a supporter of code of conducts and believe they are important/effective (I know not everyone does; I don't care for this to be a CoC debate, thanks), but I believe that they've also been very effective and successful checked in as CODE-OF-CONDUCT.txt alongside the traditional COPYING.txt/LICENSE.txt. This is a good example of a multi-layered approach working, in my view.

So acknowledging that, which problems should we try to solve at which layers? Or, more importantly, which problems should we try to solve in FOSS licenses?

Here is my answer: the role of FOSS licenses is to undo the damage that copyright, patents, and related intellectual-restriction laws have done when applied to software. That is what should be in the scope of our licenses. There are other problems we need to solve too if we truly care about user freedom and human rights, but for those we will need to take a multi-layered approach.

To understand why this is, let's rewind time. What is the "original sin" that lead to the rise proprietary software, and thus the need to distinguish FOSS as a separate concept and entity? In my view, it's the decision to make software copyrightable... and then, adding similar "state-enforced intellectual restrictions" categories, such as patents or anti-jailbreaking or anti-reverse-engineering laws.

It has been traditional FOSS philosophy to emphasize these as entirely different systems, though I think Van Lindberg put it well:

Even from these brief descriptions, it should be obvious that the term "intellectual property" encompasses a number of divergent and even contradictory bodies of law. [...] intellectual property isn't really analagous to just one program. Rather, it is more like four (or more) programs all possibly acting concurrently on the same source materials. The various IP "programs" all work differently and lead to different conclusions. It is more accurate, in fact, to speak of "copyright law" or "patent law" rather than a single overarching "IP law." It is only slightly tongue in cheek to say that there is an intellectual property "office suite" running on the "operating system" of US law. -- Van Lindberg, Intellectual Property and Open Source (p.5)

So then, as unfortunate as the term "intellectual property" may be, we do have a suite of state-enforced intellectual restriction tools. They now apply to software... but as a thought experiment, if we could rewind time and choose between a timeline where such laws did not apply to software vs a time where they did, which would have a better effect on user freedom? Which one would most advance FOSS goals?

To ask the question is to know the answer. But of course, we cannot reverse time, so the purpose of this thought experiment is to indicate the role of FOSS licenses: to use our own powers granted under the scope of those licenses to undo their damage.

Perhaps you'll already agree with this, but you might say, "Well, but we have all these other problems we need to solve too though... since software is so important in our society today, trying to solve these other problems inside of our licenses, even if they aren't about reversing the power of the intellectual-restriction-office-suite, may be effective!"

The first objection to that would be, "well, but it does appear that it makes us addicted in a way to that very suite of laws we are trying to undo the damage of." But maybe you could shrug that off... these issues are too important! And I agree the issues are important, but again, I am arguing a multi-layered approach.

To better illustrate, let me propose a license. I actually considered drafting this into real license text and trying to push it all the way through the license-review process. I thought that doing so would be an interesting exercise for everyone. Maybe I still should. But for now, let me give you the scope of the idea. Ready?

"The Disposable Plastic Prevention Public License". This is a real issue I care about, a lot! I am very afraid that there is a dramatic chance that life on earth will be choked out within the next number of decades by just how much non-degradeable disposable plastic we are churning out. Thus it seems entirely appropriate to put it in a license, correct? Here are some ideas for terms:

  • You cannot use this license if you are responsible for a significant production of disposable plastics.

  • You must make a commitment to reduction in your use of disposable plastics. This includes a commitment to reductions set out by (a UN committee? Haven't checked, I bet someone has done the research and set target goals).

  • If you, or a partner organization, are found to be lobbying against laws to eliminate disposable plastics, your grant of this license is terminated.

What do you think? Should I submit it to license-review? Maybe I should. Or, if someone else wants to sumbit it, I'll enthusiastically help you draft the text... I do think the discussion would be illuminating!

Personally though, I'll admit that something seems wrong about this, and it isn't the issue... the issue is one I actually care about a lot, one that keeps me up at night. Does it belong in a license? I don't think that it does. This both tries to both fix problems via the same structures that we are trying to undo problems with and introduces license compatibility headaches. It's trying to fight an important issue on the wrong layer.

It is a FOSS issue though, in an intersectional sense! And there are major things we can do about it. We can support the fight of the right-to-repair movements (which, as it turns out, is a movement also hampered by these intellectual restriction laws). We can try to design our software in such a way that it can run on older hardware and keep it useful. We can support projects like the MNT Reform, which aims to build a completely user-repairable laptop, and thus push back against planned obsolescence. There are things we can, and must, do that are not in the license itself.

I am not saying that the only kind of thing that can happen in a FOSS license is to simply waive all rights. Indeed I see copyleft as a valid way to turn the weapons of the system against itself in many cases (and there are a lot of cases, especially when I am trying to push standards and concepts, where I believe a more lax/permissive approach is better). Of course, it is possible to get addicted to those things too: if we could go back in our time machine and prevent these intellectual restrictions laws from taking place, source requirements in copyleft licenses wouldn't be enforceable. While I see source requirements as a valid way to turn the teeth of the system against itself, in that hypothetical future, would I be so addicted to them that I'd prefer that software copyright continue just so I could keep them? No, that seems silly. But we also aren't in that universe, and are unlikely to enter that universe anytime soon, so I think this is an acceptable reversal of the mechanisms of destructive state-run intellectual restriction machine against itself for now. But it also indicates maybe a kind of maxima.

But it's easy to get fixated on those kinds of things. How clever can we be in our licenses? And I'd argue: minimally clever. Because we have a lot of other fights to make.

In my view, I see a lot of needs in this world, and the FOSS world has a lot of work to do... and not just in licensing, on many layers. Encryption for privacy, diversity initiatives like Outreachy, code of conducts, software that runs over peer to peer networks rather than in the traditional client-server model, repairable and maintainable hardware, thought in terms of the environmental impact of our work... all of these things are critical things in my view.

But FOSS licenses need not, and should not, try to take on all of them. FOSS licenses should do the thing they are appropriate to do: to pave a path for collaboration and to undo the damage of the "intellectual restriction office suite". As for the other things, we must do them too... our work will not be done, meaningful, or sufficient if we do not take them on. But we should do them hand-in-hand, as a multi-layered approach.