Any communication system that needs to be extended at the protocol level will always privilege developers and implementers over the people who use the system. We must keep the protocols as dumb as possible and build systems where the semantics are extended by everyday people at the message level and implementers pave the cow paths.

@aral I watched you on Al Jazeera. Good interview. Congratulations.

@mariadocarmo Thanks, Maria :) Here’s hoping such things have an effect. I’m not sure, honestly, but it’s worth trying.

@aral You're welcome. You should keep trying.

We need different opinions to build a better world for all of us.

@aral this is what I try to explore with Beaker. you can still use the "old" api for most things that are now modernized, simplified.

@aral while I agree with this, I'm sort of worried about mismatch of capabilities between clients and implementations.

@ao I feel that’s inevitable and part of the organic nature of such a system. Encouraging that sort of organic use-driven evolution is part of creating a system reflective of its community.

@aral That's true. I assume such a system would benefit from openness (most if not all projects related to it being open source / libre) and easy hackability (support for scripting in said projects if they aren't easy to modify, for platforms like iOS where you need expensive hardware and an expensive dev account).

So, for example we should just type ":D" instead of using emoji?
I'm all for doing that, but I'm not sure if that's what you mean...

@aral and also: write clear documentation for beginners.

Do you have examples in mind? Because stated like this, I think quite the opposite: comm protocols are for machine-to-machine, and the programs that listens on these ports. Transport should not carry semantics

Sign in to participate in the conversation
Aral’s Mastodon

This is my personal Mastodon.