#rhizo — Public Fediverse posts

I’ve been seeing #sociocracy come up; in the #Amiko Rails fork, in conversations about double-linking and networked orgs, more than once in the last couple weeks.

Genuine question if you’re using/used it: why does it matter to you? If you’ve gone beyond the theory, what problem did it solve that flat consensus or plain voting or other mechanisms didn’t? And where does it break down?

Trying to understand if this is something worth designing for #Rhizo in the future as three mentions in two weeks is not a coincidence.

I’ve been seeing #sociocracy come up; in the #Amiko Rails fork, in conversations about double-linking and networked orgs, more than once in the last couple weeks.

Genuine question if you’re using/used it: why does it matter to you? If you’ve gone beyond the theory, what problem did it solve that flat consensus or plain voting or other mechanisms didn’t? And where does it break down?

Trying to understand if this is something worth designing for #Rhizo in the future as three mentions in two weeks is not a coincidence.

Week 2 of building docs for #Rhizo and back to an old challenge I haven't thought about in a few years: how do you write about common software industry terms that may come across as insensitive or offensive to some people?

Example of the week: blind signature https://en.wikipedia.org/wiki/Blind_signature

The audience is part people familiar with cryptography, and part experienced software engineers who aren't as familiar with it but want to learn.

Defaulting to the industry standard makes sense because that's what everyone calls it, but it feels bad - suddenly it's "blind this, blinds the token, signs blindly," etc.

Using an alternative term (hidden, disguised, obfuscated) may also alienate the audience who expects to hear about, well, blind signatures.

This matters to us because the app itself is also supposed to be accessible to a wide range of people, so the docs should be an extension of that.

What's the best approach here?

#accessibility #inclusion

Week 2 of building docs for #Rhizo and back to an old challenge I haven't thought about in a few years: how do you write about common software industry terms that may come across as insensitive or offensive to some people?

Example of the week: blind signature https://en.wikipedia.org/wiki/Blind_signature

The audience is part people familiar with cryptography, and part experienced software engineers who aren't as familiar with it but want to learn.

Defaulting to the industry standard makes sense because that's what everyone calls it, but it feels bad - suddenly it's "blind this, blinds the token, signs blindly," etc.

Using an alternative term (hidden, disguised, obfuscated) may also alienate the audience who expects to hear about, well, blind signatures.

This matters to us because the app itself is also supposed to be accessible to a wide range of people, so the docs should be an extension of that.

What's the best approach here?

#accessibility #inclusion

Alright, so I'm pretty much done with the static site generation for #Rhizo docs.

I've used Zine (by @kristoff) and it's excellent. Sometimes it shows that it's still an early project (like missing .reverse on arrays), but overall it's been a blast.

Looking forward to flipping the publish switch once the content is ready. ;)

We spent a lot of this year building an end-to-end encrypted app that we call #Rhizo (short for Rhizome).

It’s been in our heads for years and we’re finally getting to the stage where it’s about to escape into internal testing and validation.

Rhizo is built for when a secure group chat stops working when trying to organize something, and the only alternatives are often paid corporate tools; some secure, some not, and some where the ownership/values “ick” is real for people we talked to.

We’re a few months from being out of the early infrastructure weeds, which means it’s still very early BUT there’s finally something worth sharing instead of just building (which often looked like key and identity talks during toddler naps and late night coding for @siwek).

Beyond open sourcing it this year, the next big step is making all the technical documentation public and legible so other people can look at it, poke the thing, and maybe contribute code, ideas, words, etc.

While I’m here, I’m also coopting #BuildingRhizo so I can look back on it and remember it one day (when we’re older and sleeping more).

Onwards, and looking forward to any ideas, questions, suggestions and even intros or tagging people who might need it and we should meet on this journey!

We spent a lot of this year building an end-to-end encrypted app that we call #Rhizo (short for Rhizome).

It’s been in our heads for years and we’re finally getting to the stage where it’s about to escape into internal testing and validation.

Rhizo is built for when a secure group chat stops working when trying to organize something, and the only alternatives are often paid corporate tools; some secure, some not, and some where the ownership/values “ick” is real for people we talked to.

We’re a few months from being out of the early infrastructure weeds, which means it’s still very early BUT there’s finally something worth sharing instead of just building (which often looked like key and identity talks during toddler naps and late night coding for @siwek).

Beyond open sourcing it this year, the next big step is making all the technical documentation public and legible so other people can look at it, poke the thing, and maybe contribute code, ideas, words, etc.

While I’m here, I’m also coopting #BuildingRhizo so I can look back on it and remember it one day (when we’re older and sleeping more).

Onwards, and looking forward to any ideas, questions, suggestions and even intros or tagging people who might need it and we should meet on this journey!