Thanks for these links. I'm default skeptical of new things, particularly new things that look like startups, or hide behind a waitlist, or don't work on Firefox. However, Erlend has karma with me, and I had missed this talk. I just created an account on roomy.chat if anyone wants to try it out. Does this link work for others? It's possible it requires us to bind our own domain name..

one wants to avoid to re-invent all of personal computing just to do some note taking and collaboration

It doesn't hurt to start with writing and expand from there :)

As for my current thoughts on replacing Slack: we're spoiled for choice, in a bad way. There are so many different ways to approach this, all with tradeoffs that I personally don't have time to evaluate (for now). So the very first problem to be solved is social: who is available to work on this problem, and when? Also, choosing something like AT Proto or ActivityPub or Gemini or similar alternative/variant is downstream of design questions like "what are our cultural values?" and "how do we want to be empowered?". So yours is a fine question, I'm just ill-positioned to answer it right now. <3

We do have confirmation that people are able to use my link above to kick the wheels on roomy.chat. I'm going to try to keep it going. I've called it Freeing our Computers, as a compromise between FoC and Freewheeling Apps. It has a plausible affordance for going from chat to threads to pages with links that are accessible outside the community, and I'd love to test with others how well it works over time.

I had to authorize roomy.chat with my bsky account first, then click the link here a second time to add the room

Interesting!

One thing to be aware of: it's still alpha software. I gather the server goes down and periodically gets reset.

blog.muni.town/roomy-chat-alpha-2

I had the same experience as Ivan

Huh, It got added to the sidebar twice for me, and clicking on either of them deadlocks the app until I go back and click on your invite link again

On one of my devices I'm no longer able to see the channel and category I created. So definitely half-baked.

FYI: it’s all totally pre alpha , BUT we could play around with it …

Do y'all still see the channel I created?

no, but I see a picture for the icon(s) now

dont see any channels actually

replies look nicer suddenly 🤷‍♀️

Andreas S yea totally, I do think the 'every member keeps a copy of the data' model is the right way, and I like that they seem to be doing P2P in a workable way

dont quite get the vision of what 'digital gardening' means yet

Oh you can see the stuff on the main pane even if the channel list is missing. I can't see either.

only via the invite link, if i click on the icon to the left im locked out

the two buttons on the left pane, and the two buttons top center seem to work tho

ok, seems to be that there's a built in wiki, and you can retroactively make things threads

kinda zulip style? havent used that app much

@Spencer Fleming check this out for gardening, IMO it’s what we have been doing here for years, they just found a nice label for it :), in my Zettelkasten I call it “Begriffsgenese“

blog.muni.town/chatty-community-gardens

ok, if I understand it right, it's about going up the formality from Chat -> Thread -> Wiki Page / Article, in as seamless a way as possible

zulip does a similar-ish thing. Every chat has to be started with a Topic

or can be pulled out retroactively if someone notices things have diverged

and those stick around, so it becomes kinda equivalent to a forum with a general category + the topic is the title of the post

Zulip seems to have chat + threads, but no equivalent to wiki pages.

i dont think it has a wiki feature tho, yea

it is a kinda neat way of trying to get both chat & forums in the same place

i dont totally know how I feel abt it yet though

only use it to keep up with sandstorm.org and i havent quite learned to use it properly so far

digital gardening seems not so totally far off an idea from the wikipedia talk page tbh: en.m.wikipedia.org/wiki/Talk:Ranavalona_I

which is a good sign

Community - wisdom and vision gardening

youtu.be/v5dBRmjF8mc

Woah, they launched something? I was on their Google Group from 2021 but it got quiet real quick: Playbit - Google Groups

Just tried it out. Really like the vision in playb.it/careers , and it's quite pretty, but I don't quite get how to access the shared workspace features

Maybe its not in the alpha yet, or maybe I just missed where to look for it, not sure

Either way, thanks for the link

I tried it out a while ago. It works, and looks pretty, but I don't see anything useful I could do with it at this stage.

Are you running it as a VM? Or booting from it? (I don't have access yet)

If you sign up with an email, they send access right away

I signed up and got in within a minute

& running on qemu since I don't have a mac

My take is the same as Konrad's rn: it has what looks like a lovely UI framework and window manager but not a lot else, and the neat part about sharing state across installs isn't implemented yet

I talked to this girl at Amazon one time who said that their whole team had enabled remote desktop control on each other's work computers to make collaboration easier

Not as vibey, but sounds like they were solving for the same problem

Yeah, I keep going back and forth on if I think real collaborative multiplayer is worth the hassle

Compared to the easier solution of having a single thread with optionally a VM migration to move it closer to you as a performance enhancement

Or the easier still solution of just having a nice screen sharing

Arcan , a project I love , is doing some neat stuff x11 style of remotely starting processing and streaming in the result, to do things like running the web browser on completely separate hardware set to reimage itself when the window closes.

And you don't have to learn CRDTs :p, which seem neat but having to add conflict resolution everywhere does seem like it complicates things

I ran playb.it via qemu. No need to sign up anywhere, just download the image from playb.it/alpha

I want to respond to this point, since I think it's a good stand-in for many of your other criticisms of the schematic:

It is too complicated, it contains too much nuance and detail, the DI (Design Intent) is not obvious. Someone tried to improve the DI by colourizing the schematic, but, it still looks to be too complicated.

I'm not an EE, but I did spend almost 20 years working for a schematic "programming" company. To me, this schematic is about the typical complexity I'm used to seeing before you spill over to multiple pages. And the schematics I'm used to working with would come by the hundreds, bound in massive 3-ring binders, all describing a single piece of industrial equipment (like a single bulldozer or excavator).

So going by gut, this schematic feels about as "complicated" as few hundred LoC, in that it'd probably take me about as long to do a cursory scan or deep read of either — less than a minute to survey the broad structure, a few minutes to identify patterns, and maybe 20 minutes to deeply go over everything.

Is that "too complicated"? Too complicated… for what?

Without presuming too much about your background (for instance, I wouldn't be the least bit surprised if you were an EE with lots of schematic-reading experience and still held this opinion), I think it's interesting to work through your "too complicated" reaction in a few ways.

• How much of this detail and nuance is due to the design of schematics as a visual communication medium? Is there a different way of visualizing an electrical system that would be easier to read, while still being useful for the same purposes? Well, what's the purpose of a schematic? I believe they're primarily intended as documentation, useful if you need to repair an existing system to verify how it is supposed to work — they're a known-good reference you can compare your faulty system to, to identify short / open circuits, damaged components, etc. And, sort of like sheet music, these schematics elide plenty of information, such as the placement of components and routing of trace/wires — they aren't like blueprints. So maybe we could find a different way to do the same job, or a different way to do a different job, by choosing to elide different information. Or maybe we need to overhaul the "symbol language", so that instead of capturing information about what the components are and how they're connected, we capture information about the dynamics of the system. (Bret shows something like this in Inventing on Principle, but none of the EEs I showed it to found it at all compelling 🤷.) So — would your criticism be addressed if we changed the standard design of electrical schematics, and if so, how and why?
• You rhetorically ask how many pieces of paper it'd take to hold the code for Pong in a modern language. I think that's a fascinating comparison. To make it fair, we'd probably have to find some way of normalizing the I/O APIs so that they're the same as what's available to schematic. After all, if there was a "runPong()" API that'd be unfair. Would the Canvas2d API be fair or unfair? Etc etc. My gut is that if you did this normalization, you'd probably end up with code that felt to a typical coder about as "complicated" as this schematic would feel to a typical EE. After all, they'd both be doing roughly the same thing, and I don't think Pong is inherently complex enough to benefit from the sort of abstraction-building that makes code so powerful. (That's my gut sense, at least.) But maybe you disagree, and the code would be fundamentally different in some way that'd change how complicated it appears.
• The schematic uses space and visual symbols in a way that's fundamentally different from textual code. When you computerize the schematic, you can animate it, and reveal all sorts of information about the runtime dynamics of the system. At that point, I think the schematic is significantly more expressive than the equivalent textual code. So maybe, in the absence of that augmentation, the visual "juice" isn't worth the complexity "squeeze", so to speak.

Anyway, thanks for the post. Hit the spot!

Yes, I learned to read schematics on my own, then I got an EE degree (which got me into compiler-writing! One 4th year course was "pick your own topic for the next two terms". Right at that moment, DDJ came out with its SmallC compiler article and my wire-wrapped Z80 was itching to be commanded (this was in an age of closed-source, so seeing other people's code was refreshing (the other thing I carried around in my briefcase was the source code to V7 UNIX)).

I don't think that schematics are better than code, nor that code is better than schematics. I think that they both suffer from containing way too much detail splayed out in a meat-tenderizer method (bigger means wider, not taller (layered)). Both are difficult to understand unless you get a degree or misspend your youth learning their secrets.

I do note:

• when I built and debugged electronic circuits, I would be confident that they could be shipped with 0 bugs
• when I build code, I always expect more hidden bugs to surface
• I perceive our current software workflow as supporting the shipping of buggy designs (CI/CD, convincing unwary customers that they should act as our Q/A departments for free instead of suing us for selling them buggy products, quarterly Continuous Delivery updates, etc.)
• I observe a major difference in the two techniques: code is sequential and synchronous, electronics is asynchronous and highly parallel even at low levels (cheapo ICs like the 7400 series)
• I observe that both techniques are "too complicated" for getting a design overview
• both techniques suffer from strongly-connected scoping - wires/globals poke through sides of sections and directly tweak the innards of sections.
• debugging async systems was easier with hardware tools, like 'scopes, meters, than is debugging code with single-stepping debuggers and the plethora of doo-dads that have been pastied onto the single-stepping techniques to make them multi-thread-stepping.

Sooo - what are "the good parts" of each? Can we pick and choose? I think that my 0D (PBP - Parts Based Programming) stuff is a step in that direction (surprise!). A system should be composed of multiple Parts, Parts must have well-defined Ports and must not allow their innards to be visible, tweaked, called by other Parts, i.e. data flow only (whereas FP transfers dataFlow+controlFlow). A system should be understandable in small (7+-5) chunks, digging deeper only by those interested in more detail (kinda like the colourized Pong schematic with all of the schematic details erased at the top level). It should be easily possible spray a design over multiple CPUs (functional thinking discourages that kind of thing due to its very low level over-synchronization / clockworkiness). Imagine each coloured box on the Pong diagram sitting on a separate Arduino with only thin wires connecting them through well-defined ports (my Wang word processor had a "bus" with 400 point-to-point wires on it to interconnect circuits plugged into the backplane - the S100 bus was much more general, hence, better and a breath of fresh air).

[I have a "The Good Parts" article sitting on my disk, unpublished thus far. A lot of our programming techniques are based on 1960s biases, like concern for "efficiency". We should know better by now]