Notices by Grey Area (greyarea@mitra.vpclmulqdq.moe)

@silverpill @yggverse

Depends on how much TLS you want. Root of trust is centralized (certificate authorities). With CA certs cached, unless you care about revoked certs (which in extreme cases you don't), adding cryptography is cheap.

@silverpill

Even if you don't use this exact framework/constructions, this provides a good overview on the properties you can expect from how to combine key exchange + symmetric encryption.

https://noiseprotocol.org/noise.html

@silverpill @raucao @lain @sozialwelten @koteisaev

As a note, FEP-0806 is overly simplistic in that it has no forward secrecy.

As an easy improvement, if the sender also generates a per-message ephemeral X25519 keypair, you can do static-static + static-ephemeral KEX and get imperfect forward secrecy (no additional round trips required).

@silverpill

It's platform agnostic since it's "just" a browser window. I should better separate the front/backend so someone can write something nicer, but I have been busy with other commitments lately.

@japananon uses it with peertube

Seeing as the original Shadowchat author and repository vanished into the ether, and none of the forks are getting active development, I have decided to start maintaining the project.

Main changes from the surviving forks (LukeSmithxyz, Shadowchatjp):

- Internals rewritten to not "read/write from CSV files from the httpd handler routines, without locking, as a means for persistence and IPC".
- Config file format changed from JSON to YAML.
- Structured and leveled logging.
- Localization is now a first-class feature.
- Static assets and the dynamic asset templates are now embedded in the executable at compile time.
- The OBS widget (/alert) should function better now.
- The history view widget (/view) now has optional auto-refresh.
- HTTP basic auth is no longer used (alert and view now both use the authkey).
- Optional support for including a logo in main "make a shadowchat" page.
- Optional support for an integrated captcha.
- Japanese localization included by default.
- Minor UI cleanups.

Warnings:

- This was only lightly tested with the XMR stagenet.
- Upgrading will lose all historical chats, because fuck writing an importer.
- I am not a web developer.

https://gitgud.io/greyarea/shadowchat

@silverpill

Ah, the RTC that started as draft-thomson-postel-was-wrong. For something that needs to be extensible, I'm not sure "reject anything unusual" is ideal, though that depends on how you define "unusual".

Without a in-depth understanding of what the ActivityPub protocol actually looks like, I'm not sure if having something like GREASE (RFC 8701) would be applicable or useful...

@japananon @romin @prettygood @djsumdog

Am I the only person that has sold plasma for weed/booze money?

@japananon @silverpill @bronze @captain_arepa

https://codeberg.org/silverpill/mitra/src/branch/main/contrib/docker/Dockerfile

@silverpill

Thanks for the advanced notice!

FWIW, RHEL9 variants only ship up to NodeJS 16. Not a big deal since the nodesource repository provides more modern packages, and switching was trivial.

@silverpill @Revertron

So something like certificate transparency logs, but for identities?

@silverpill

Nice thing about FROST is that it already works with did:key with Ed25519, since signatures and public keys are compatible. secp256k1/secp256r1 are not, since FROST is Schnorr signature based rather than ECDSA.

As far as the gap goes, IMO that's where crash fault tolerant consensus algorithms (Paxos, Raft, etc) fit in. Non-POW Byzantine fault tolerance tends to be tied to Shitcoinery because the systems only allow up to < 1/3rd of the participants being malicious (2f + 1 need to be non-Byzantine), and the "best" way that's been found is economic incentives.

The original PBFT paper/research from 1999 used a NFS file-server implementation as the practical example, but "people are assholes, and someone will spin up a mountain of nodes" isn't something that was in-scope when they did the research.

@silverpill

In a permissioned setting (assume 0 malicious actors, and only need to be crash fault tolerant rather than Byzantine fault tolerant), just use Raft or something.

As far as N-of-M threshold signatures goes, FROST isn't too bad to implement.

https://github.com/ongardie/dissertation
https://cfrg.github.io/draft-irtf-cfrg-frost/draft-irtf-cfrg-frost.html

@silverpill @fentiger

The Rust URL library is correct, according to spec (none of the updates change the behavior here).

https://www.rfc-editor.org/rfc/rfc3986#section-3

@silverpill

>Any particular feature or features you'd like to see implemented?

TOTP based 2FA? Though it's low priority since my instance is just for myself.

@japananon

Given the only things I've heard wrt to XMR and Binance are conspiracy theories (that are probably at a minimum, partially true) and bitching, was Binance a significant source of liquidity in general to begin with?

@silverpill

The DDoS outages are maximum sadness.

https://status.codeberg.eu/status/codeberg

@silverpill

>doesn't require any fancy cryptography

For what it's worth, if you have questions about implementing MLS or other applied cryptography, please feel free to ask.

@mint @japananon @Pawlicker

>Majority of artists I've seen happen to be not too techincally inclined, to say politely, and also strong conformists rejecting whatever hivemind deemed bad (AI, crypto).

I don't blame them. The vast majority of both generative AI and crypto are bullshit that should be rejected.

Mitra is pretty great. XMR is pretty great. AI when used for creative purposes is pretty great.

The counterpoint is, the overwhelming majority of crypto is poorly designed/coded bullshit, And AI is the current buzzword de jour.

It takes a fairly informed understanding of AI and crypto to discern the value proposition, and I'd rather the art people focus on art rather than becoming technologists.

Of all the various sorts of shitcoins I've had to interact with programatically, XMR has been fairly painless so far, and I hate it significantly less than anything resembling ETH (and the web3 trashfire).

The main thing I'm not super thrilled with is having to rely on monero-wallet-rpc. If the node RPC, wallet/key format, and integrated address generation algorithm are all sufficiently documented I may just write my own client that can talk to a node.

I did say that I will work on the third party client API for shadowchat 0.2.0 next, but "write my own wallet RPC library" sounds more fun...

As an unsolicited opinion since smart contract languages came up in my feed, the whole "smart contract" concept is nice in theory but terrible in practice, because:

- Regardless of language[1], people can't code their way out of a wet paper bag.
- The testing/debugging/verification tooling is one of non-existent, shit,
or complicated/exotic[2].
- By it's very nature, errors lead to irreversible damage, and architectural changes that mitigate "programmer fucked up, sorry for your loss, have fun staying poor" go against the crypto ethos.

I want my digital currency alternatives to be as stupid as possible, and as private as possible (which also is a losing battle due to politics, but that's another rant).

[1]: Not even crab-lang can save your smart contract from developer errors. https://www.certik.com/resources/blog/1kDYgyBcisoD2EqiBpHE5l-wormhole-bridge-exploit-incident-analysis
[2]: See https://github.com/AU-COBRA/ConCert for an example of tooling that should be mandatory.