You are reading content from Scuttlebutt
@SoapDog

Just wanted to float an idea for you folks and gauge some opinions. I am not working on this that I am going to talk about, this is just an idea that has been floating in my mind for a while and if I don't talk about it I will end up forgetting it and never getting any feedback.

What about a playground for SSB?

As mentioned in other threads from @mix and @Matt McKegg, creating and experimenting with SSB is not as friction-free as we'd like it to be.

I think we'd benefit from a Playground for SSB software. I'd like to think of it as a little UI like a Lisp Listener, a REPL that would allow you to execute little scripts against the running sbot with a nice API.

This way, inventive users could just pick the app and toy with little scripts. The approach would be something similar processing in which not only you have a nice API but also some good visualization tools for the result of your toys. I don't mean this as in good enough for interactive graphical artists (which is hard to build) but at least something that goes beyond ASCII dumps.

I think that JS is the wrong language to build this as the facilities for executing scripts interactively are lacking. We can't trust eval() not to mess the current environment and the language carries a ton of baggage these days in terms of associated tooling to benefit from the latest and greatest features. I've been thinking about using a different language to create these interactive environments, which would be possible once #sunrise-choir becomes more ready for experimentation.

All this talk is just context, I believe everyone would love to have such app. What I am trying to get specific feedback is on the two approaches forward outlined below.

The Lua approach

lua25.gif

Lua is a fantastic tiny language. It is very speedy and easy to learn. It has been around for 25 years now and has carved some niches for itself. Some pros for this approach would be:

  • Fantastic FFI interfaces (both in LuaJIT and PUC Lua) allowing us to interface well with #sunrise-choir or any other approach that is callable as a shared library with C conventions.
  • Built for scriptability from the start. Lua has always been an engine that you're supposed to embed into a larger program to expose said program features to a scripts. It has a very good API for wrapping C stuff back and from Lua, which would allow us to create a really nice API.
  • Lua is very good in executing Lua code with constraints. You, from inside a Lua program, can craft an little environment and choose what globals, what functions, what features, a runtime script can have access to, thus allowing you to execute code written at runtime without the danger of breaking the running environment. This is the main reason for me to use it over JS for this kind of app.

There is a software product called tarantool which is at the same time a non-relational database, an application server and a fast Lua engine. This app could be built on top of Tarantool with the feed going inside Tarantool database much like @Piet has been experimenting with SQLite but with the added benefit of having a full server and scripting engine in the same tool.

The final deliverable would be an engine. This engine has the SSB features and a running scripting environment offered as a REPL or something that works over Standard Input/Output thus also allowing to build little tools on top of it.

The Racket Approach

Racket is a language in the Lisp/Scheme family that is thought as a toolkit for building languages. I have used it in this talk about JS monoculture to build my own little programming language for crafting slideshows.

With Racket, we have the opportunity to build a little language that just suits SSB. Just like Perl knows all about handling text, we could just have a language that knows SSB. I don't mean a language in the Lisp family with an SSB API, I mean any language we want that has SSB as primitives in which it is built upon. The book Beautiful Racket is a very nice book on constructing small languages. Some more of the pros for Racket are:

  • It has a good FFI as well, thus allowing us to leverage #sunrise-choir stuff just like the Lua approach above.
  • Allows us to create a full language.
  • Provides a rich environment with editors, graphics, interactivity out of the box for the language we create.
  • Any language built with Racket can use the other languages built with it, this is very powerful as it allows us to craft a low level language (something like scuttlebutt system language) and then build a high-level language (like a buttscript) that uses the low-level language internally.

Conclusion

So, I have these two ideas in my mind. I have no idea if anyone finds them interesting. I am not working on them now, I am just collecting ideas for future projects. Personally, I think that the Racket approach might lead to a very good software in the end, something that is quite powerful. While the Lua one leads to faster stuff, both in terms of development time and also of execution time.

Anyone want to share some feedback?

User has chosen not to be hosted publicly
@aljoscha

I don't know anything about the binding story for racket/rust, but there's a really nice crate for lua/rust interop: rlua. Creating lua bindings to the rust implementations should be fairly low-effort (especially compared to js).

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@SoapDog

@alanz the battery-include-ness of Racket is soooo good. Have you played with approaches like the ones outlined in Beautiful Racket? You end up with a full graphical IDE for your own tiny language. I am thinking that this is a good way forward. The best thing would be to reimplement all parts needed for a ssb-client in Racket, so that it uses WebSocket to talk to a running sbot in whichever language it is built.

@Aljoscha and @Rupert Lua is damn great. Every time I do something with it I am happy. I used to blame that to the fact that I studied in the University where it was invented for a while and that was hammered into me but the fact is that it is a very fine language (and I like 1-indexed arrays). As for rlua be aware that it doesn't support _ENV so we can't craft those protected environments I mentioned before.

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@SoapDog

@alanz but Racket doesn't need to look like Lisp. You can use it to build a language just like Lua if you want. For example, the slideshow language I built with Racket looks like this:

nanodeck sample.jpg

As can be seen, it doesn't look lisp at all. The source for it is at the nanodeck repo on github

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@SoapDog

@alanz oh I didn't knew that... good to know! My tentative plan is to look into this once I release the beta of patchfox later this month.

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@Sam Hart

@SoapDog looks like there are some parallels between the REPL system you're describing and a project I'm involved in, radicle. We're building on top of IPFS because global visibility of messages is an important requirement for our use-case, but we want to write an interface for sbot at some point as well. I don't think it's a replacement for what you're describing, but has similar motivations.

@SoapDog

@punkmonk I haven't given it much thought yet, but I believe that it is contained in this subset:

Modules · GitBook - Firefox Nightly 2018-12-20 15.03.33.png

What we can see there circled is the part of scuttlebutt the I usually think as a client. I don't think necessarily that the flume stuff enter into it. I'd be happy with a Racket based set of modules that talk to a running sbot implemented in JS or Rust.

@SoapDog

@hxrts I just looked at the link you sent. Yes, there is an overlap there somewhere even though we're not sure where specifically it is. I just did a cursory look on the page and then navigated to the page about black. Can you share why you settled on that approach to scheme? What kind of stuff you need at metalevel that made other schemes unsuitable. I am a Scheme newbie even though I've played on and off with it for the last 20 years...

@Sam Hart

I'll do my best to compare ssb & radicle though @jkarni & @jameshaydon may want to chime in as well.

Scuttlebutt is person-centric—each person/device has their own chain representing a log of events they've seen, where event messages have a consistent header + optional fields for different message types (ex. gatherings).

Radicle is program-centric—each program has its own chain representing an application-specific state machine, where every message contains a state transition update. The metalevel/reflective programming allows you to modify the state machine semantics on the fly by making a state transition that redefines that chain's own eval function.

The radicle paper explains some of the design decisions in more detail. The first use-case, and the one we're focusing on, is code collaboration, so sync-ing git repos, issues, etc., but it's a pretty flexible system.

Honestly, we're still figuring out where exactly ssb & radicle overlap. I spoke with @cel a couple weeks ago to see if there was a way to support his git-ssb work. I think it's still a little early to tell how the protocols might play together, but the two paradigms seem like a natural fit and I'm sure there are lots of cool areas to explore. Any & all ideas from the scuttleverse definitely welcome!

User has chosen not to be hosted publicly
@masukomi

ok, i have to be the old guy in the back of the room here @SoapDog .... Smalltalk probably has the most exceptional playground and experimentation ui / toolset of anything out there... and it's been ported to javascript. Now, I suspect most of the amazing visualization tools that it has don't work in JS+HTML land but... you gotta look to the land of Smalltalk when considering ideas like this because they've already done so much and it's ... just such an amazing trove of ideas to mine. I love lisp and scheme (Racket)... but dayum you want a good experimentation playground... nothing beats Smalltalk.

@Fabián (deprecated)
Voted this
User has chosen not to be hosted publicly
@SoapDog

@masukomi I can't agree more with you. I am a huge fan of Smalltalk as well. Have you seen the new visualization stuff that they have for pharo? It is mind blowing.

I think that is a good path forward for this kind of exploration but I don't really know how Smalltalk (Squeak or Pharo are the only ones I have any experience) play with JSON decoding. Do we need to map it into an object? Oh, I just did some googling and found about NeoJSON which gives you back dictionaries and arrays. Yes, this can be used as well.

We should have multiple teams doing this kind of stuff auhahuauhahu so, I am tempted to start with Racket and then maybe later try doing it in Pharo. Mostly because I am already trying to do some racket stuff and I am attracted to parenthesis (whats the plural in english or parenthesis?).

For those who never seen Smalltalk or Pharo, check this visualization talk: The Glamorous Toolkit, towards a novel IDE which uses the Glamorous Toolkit (which uses roassal below it I think) to create some really freaking amazing stuff.

@alanz you might enjoy the talk I linked above.

@bobhaugen

I developed my skunkworks project in the mid 1990's using Smalltalk. Took processes like MRP that ran as overnight batch jobs and did event-driven reactive replanning in near-real-time, always updated.

That was the first project in the stream that led to #valueflows .

I loved Smalltalk. I could code in the debugger. Just get something started and carve it into shape while it's running. (Some Smalltalkers thought that was a bad practice, but I found it fit the way I think.)

Unfortunately, the Smalltalk community at that time was tangled up in proprietary vendor competition and also did not grok the Web.

Wasn't until Squeak, which led into Pharo, that it started to come alive again, but by that time, it was too late for me.

@jameshaydon

What kind of stuff you need at metalevel that made other schemes unsuitable

@hxrts 's answer is already pretty complete, but I'll just add: Radicle is inspired by Black in that one can change the eval function, which is what gets executed everytime a new state machine input comes along. The sort of eval-redefinition that is available in radicle is much less powerful than in Black, but it still allows one to "lock down" the semantics of a program, e.g. disallow some inputs. This makes radicle suitable for creating state machines that ensure certain rules are followed, e.g. only inputs that are signed by one of a set of cryptographic keys may add some new code, participate in a vote, etc.

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@gozala

I would suggest considering:

  1. What is the goal of playground ?
  2. Who is your target audience ?
  3. What is going to be build with it ?

I think answers would will gives you a lot to consider, e.g.

  • How likely is for my audience to already have a setup allowing them to use playground without going through an extra mile.
  • How likely is my audience to be comfortable with the chosen language ? If you want to teach SSB teaching a new language at the same time is likely not good idea.
  • Do you expect things build with playground be useful afterwards ? If so what kind of things ? Do you think people would want to distribute / share those things ? What would be a runtime to fit best those needs ?
@gozala

BTW I a have build a playground for dat as beaker app here is the little demo dat://code.gozala.io/lib.gozala.io/~dat-night.js

My goal there was to allow quick prototyping to learn how one could easily build / share stuff on dat via beaker. I chose JS not because I'm a big fan (I'm not) but because it made it possible to just type in browser and share link so someone else could load and hack on.

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@bobhaugen

@alanz

one of the big problems with these personalised image environments (smalltalk,lisp,forth, etc) is that individual developers create their own ever more specialised worlds, which means it gets harder and harder to cross pollinate stuff.

My memory from Smalltalk coding days is of a lot of shared open-source code among a small group of people who were into it. My memory is bad and I don't have any of the code anymore, but I remember getting code from Kent Beck, for example http://wiki.c2.com/?SmalltalkUnit , and several other people. And also a market for commercial Smalltalk products that you integrated with your own code, most notably https://en.wikipedia.org/wiki/Gemstone_(database)

I don't know the situation with Pharo.

User has chosen not to be hosted publicly
@SoapDog

@gozala those are some very good questions, many of which I don't have a clear answer. I guess I just want us to have more options when it comes to playing with SSB besides JS.

To be honest it all this is a consequence of me thinking about my favorite machine, the Apple Newton, over and over again and wanting to replicate some of the cool stuff I had there such as dynamic languages that I could execute in runtime without breaking the running system. Which led me to "I want a playground for SSB that allows me to run little scripts against the feed without breaking whatever is hosting the playground" which made normal JS a bit unsuitable.

I've been playing with Racket and think that we could have a very easy to use and powerful playground built with it, something inspired by pyret or eve in which a simple language is used for the purpose of teaching and exploration with a reach friendly environment to go along with it.

I see two potential paths forward in terms of objectives, one path would be a pure teaching tool, a playful playground just for the sake of learning and having fun. Another possible objective would be a more dynamic SSB client that could inspect and change code at runtime and maybe even share code over the network (not unlike HyperCard and Smalltalk can).

To be honest, I don't know if anything mentioned in this thread is wise or good or even desirable. I am having this conversation to gauge ideas and get feedback. Maybe it will all boil down to "we just need more SSB client libraries for other languages and everyone builds their own playground"...

Also, thanks a lot for links for the DAT playground you've build, I will study it here and play with it. :grin:

@bobhaugen

@SoapDog I hope the Smalltalk chatter did not confuse the thread. I think a Racket-SSB playground would be wonderful!

@SoapDog

@bobhaugen in Pharo there are multiple ways of sharing code these days. To be honest I don't know how to use them but there is access to Git from it and also its own home grown version control stuff called Monticello. The Chapter 8 - Sharing code and source control of this PDF book gets into more detail about that.

@SoapDog

@bobhaugen don't worry. We all love them all :green_heart: :balloon:

To be honest, the easiest playground would probably be a module for #patchbay using fengari which is a Lua for the Browser. With it, one could craft a running Lua environment and fine tune which APIs it has access and so on, thus creating a safe environment for executing unsafe code. Just replace fengari-dom (module which gives access to the DOM and JS) with some sort of fengari-ssb module and poof.

User has chosen not to be hosted publicly
@gozala

@gozala those are some very good questions, many of which I don't have a clear answer. I guess I just want us to have more options when it comes to playing with SSB besides JS.

I think it's more of a question whether you want a web stack or not. There are plenty of languages today (I suspect we'll have even more once Wasm gets GC) that will become viable on the web platform that aren't JS.

Which led me to "I want a playground for SSB that allows me to run little scripts against the feed without breaking whatever is hosting the playground" which made normal JS a bit unsuitable.

Fare enough. If sandboxing is your real concern I think there are multiple options that are still compatible with JS

  1. I believe @jimpick had being playing with https://github.com/Agoric/SES that you could use to control what JS can & can not do.
  2. Web workers are another effective way to limit web worker capabilities (especially if loaded with null origin). Thins like networking are still available but I think it isn't all that difficult to take it out. In the past I've built plugin system for TomTom devices that was running plugin code in the worker and it worked fairly well.

Another IMO best option to stay in web ecosystem without JS is Wasm. All the capabilities need to be passed in already so you have sandboxing. Not so many language options right now but I suspect that will also chain as GC is added. There is also efforts in taking Wasm beyond the web stack so in theory that would provide wide range of options. That being said it may or may not be as important for your use case.

To be honest, I don't know if anything mentioned in this thread is wise or good or even desirable. I am having this conversation to gauge ideas and get feedback. Maybe it will all boil down to "we just need more SSB client libraries for other languages and everyone builds their own playground"...

Idea of writing some code and just sharing link for other to try or grow it beyond what it does is very compelling to me. That is primarily a reason I did my hack. Code you write down there is just a ES module so people can use it in Baker apps, I also wrote bunch of code that way that started as simple REPL sessions.

Using JS in my case was a compromise, in fact I was going with Elm but run into bunch of limitations and had to compromise. My longer term goal is to review wisp into a language with just binary AST representation with type system similar to Elm's which compiles to both Wasm & JS and make it p2p native (no package managers just content addressable modules where naming is just metadata stored separate from AST). But chances are high I will never get there.

Rereading what I wrote above I see I'm derailing the conversation, I apologize for this. I will still post this because I think my experience in building something with similar goals might trigger some useful thoughts.

User has chosen not to be hosted publicly
@gozala

Was not aware thanks for sharing!

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@kas

TiddlyWiki also comes in a flavour with a nodejs based ‘server’ that stores each tiddler in a separate text file. It's available from AUR as {nodejs-tiddlywiki,-git}.

User has chosen not to be hosted publicly
@gozala

@alanz Unios looks amazing! Thanks for bringing it my attention!

User has chosen not to be hosted publicly
@buoyantair

Both of these languages are of interest to me! I used Lua to make video games before and I have used racket for courses! Both are nice little languages I like :D

User has chosen not to be hosted publicly
@bobhaugen

@alanz @erde74

I'm tempted. Smalltalk was my all-time fave coding experience and also all-time most productive coding environment. But the community blew it so bad in the 1990's that I hesitate to dive in again. But if y'all get anything going with Smalltalk-SSB, I'll try it. (In my copious free time...;-)

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@jimpick

If anybody is interested, I did a multiwriter Dat + Automerge + TiddlyWiki mashup in the summer... I use it for all my notes, syncing to multiple devices.

https://dat-tiddlywiki.glitch.me/

It's probably not super obvious how it works as far the UI goes for syncing between devices, because I just built it over the bones of my older dat-shopping-list demo - but the code is there and it works, if anybody wants some inspiration.

User has chosen not to be hosted publicly
@kas
Voted this
@SoapDog

Hey @jimpick @bobhaugen @alanz and @erde74 why don't you folks join forces and just build a toy using pharo that talks over WebSockets to a running sbot on the machine? or something similar? We need more toys! :grinning:

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@Christian Bundy
Voted this
@C-Keen (work)

Can you show me how I can load this into a smalltalk image with MontiCello?

User has chosen not to be hosted publicly
@SoapDog

@alanz ohhhh this is good! Be aware that you can talk to scuttle-shell using the Native Messaging Protocol, by following these rules, you'll be able to:

  • discover if #scuttle-shell is installed.
  • start scuttle-shell and acquire configuration from it (secret, manifest, remote).

Then you can use a WebSockets connection (and reinvent all the WS stuff from SSB) to talk to it, ooooorr, we can augment the host app of scuttle shell with a minimal API. The first version of it had it, it exposed some minimal stuff for retrieving messages, posting.

@C-Keen (work) happy to see you around again. :wink:

cc @cryptix @cryptixInTheCloud @mix I think this type of experiment is a good case for us to keep the host app with scuttle shell, as I mentioned in the comments of scuttle-shell#15.

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@C-Keen (work)

Thanks for this! I have just found out that Pharo and Squeak use incompatible serialisation formats so getting it into my smalltalk system will not be easy...sigh

User has chosen not to be hosted publicly
@SoapDog

@alanz I started from sbot cli as well. No worries. Things for #scuttle-shell and #patchfox are a neverending cycle of refactoring, it should start consolidating soon and then we'll have a more solid base to build stuff on.

@C-Keen (work)

It's a fork, not the future though :smiley: You could file it out as monticello package for me if you find the time. But if not don't waste your play time, I'll find a way.

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@kieran
Voted this
@w

For a while in the early/mid 90s, someone was developing a NPAPI plugin which contained a Squeak VM. It actually made a lot of sense to me as an open Flash replacement, which seemed quite limited by comparison.

@w

I of course mean the early/mid 2000s...

Join Scuttlebutt now