p

pmf

Some thoughts about (mainly) industrial and emdedded software engineering

Federated spam list

Idea from this comment: https://news.ycombinator.com/item?id=33738231

What about federating whitelists/blacklists? Real spam is a problem for all user driven communities, and this should be seen as an orthogonal, separate issue from banning/blocking.

Mastodon vs. Matrix

Overall, I'm a bit sad that the exodus from Twitter is going to Mastodon instead of Matrix.

Matrix has a perspective for P2P1 and E2E. Putting yourself at the mercy of a Mastodon instance admin (especially when the purported reason for leaving Twitter in the first place is a supposedly evil instance admin2) seems a bit shortsighted.

With Matrix, you own your identity. With Mastodon, except for vocal lip service, the instance admin owns you.


  1. https://arewep2pyet.com/ 

  2. "nasty rocket boy" is the new "bad orange man" 

Offloaded identity verification

Instead of making people pay to get verified, also offer (maybe also only for paying users, I don't care) the ability to guarantee authenticity by allowing to associate a public signing key with the account (as hidden payload). Authors can (via client extension) sign their messages (client side), and users can then verify (either via client extensions, or via their social media network JS code) the authenticity of a message, and can even pull the public key for checking the signature from a "trusted" source (for the sake of discussion only, let's assume the website of the newspaper of the journalist publishing the message in question). See Farcaster1, for example.

If this is based on an open protocol, this alone could solve part of the "multiple accounts"/federation mess. I.e. this would completely decouple identity management from message authenticity verification: users can always go to the authoritative (third party or first party) key provider and don't have to trust the first party (i.e. the social network operator). Assuming they have out of band information about who the authoritative key provider for the person in question is.

One thing that is not solvable any other way is the case of personnel of the social media network operator publishing fake messages: under this model, they never have the private signing key, so anything they publish under the author's name fails validation (assuming user's clients have pinned the fact that this author uses external third party key; otherwise the fraudster could just change the account info to first party signing).

The majority of content producers can just use the first party (the social network operator) for both publishing and and key provisioning (per default, without knowing about it at all).

Of course, this has all the problems of normal public key infrastructure and would require a minimum of effort and care on the user side, so this does not have any chance.

The Twitter Acquisition

Two quotes.

“What the herd hates most is the one who thinks differently; it is not so much the opinion itself, but the audacity of wanting to think for themselves, something that they do not know how to do.”
― Arthur Schopenhauer

And:

“One who thinks for himself is a threat to his enemies, a refuge to his acquaintances, a prize to his friends, and a gift to the world.”
― Matshona Dhliwayo

Not playing "Bird is the Word" while carrying in the sink was a yuuuge mistake, though.

On GNU readline

Related to this great article about rather unknown GNU readline features, I'd like to point everybody at my personal favorite readline hack (not by me): https://codeinthehole.com/tips/the-most-important-command-line-tip-incremental-history-searching-with-inputrc/

Regarding the article itself:

Although GNU readline maintains a kill ring (clipboard), which works much like Emacs’s kill ring, it’s not shared with your system’s clipboard, nor any other instances of GNU readline. It is, in effect, local to the process you’re running.

Would also be nice to have a solution for making this system wide.

Also learned about M-* inserting all completions.

Cutting edge

Good news, I'm now apparently working in a hip cutting edge paradigm: https://reviewpad.com/blog/modern-trunk-based-development/

Mutable typed hierarchical environment variables

Hear me out: an architecture based on mutable hierarchical environment variables

Backed by ZeroMQ1 for messaging/IPC, SQLite for persistency (if needed), and JSON (grudgingly, since other options are even more horrible; OTOH we want to have type information, so something like protobuffers would be required) as payload.

Trivially easy subscription and property binding/propagation mechanism: stating that process X's x_out variable is defined as process Y's y_out and process Z's z_out must be allowed to be defined (within X) as x_out = Y.y_out + Z.z_out, or more generally x_out = some_fun(Y.y_out, Z.z_out), where some_fun() is some Lua function (assuming we want to use Lua as expression language). If Y or Z now change their outputs (y_out or z_out), X's x_out will automatically change. Throttling/debouncing must be possible.

Hotswapping of processes should not be ruled out.

Optionally define a framing that allows for something like Cap'n Proto's time travelling RPC.

This whole system would, of course, adhere to Virding's First Rule of Programming.

Throw in some tuple space ideas while we're at it2: .


  1. Or nanomq? Maybe a better choice regarding integration of third party software, since it contains adapters between internal IPC and external MQTT, although the last time I tried this this did not quite work. 

  2. https://software-carpentry.org/blog/2011/03/tuple-spaces-or-good-ideas-dont-always-win.html