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

@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.

@silverpill

You'll probably find the papers by the ConCert team (linked from the README) entertaining at a minimum, even if you don't care for formal methods or proof assistants.

@silverpill @k4r4b3y

>I'd like to have encrypted DMs here as well. > >Sooner or later E2EE will be implemented <https://wedistribute.org/2023/08/sup-by-pixelfed-is-coming/>

Oh boy, MLS. I wonder what they are doing about the "protocol assumes a trusted authentication service" component of the design. This isn't required (see 16.10 of the RFC), but adding more complexity onto what is a complicated protocol is spooky.

https://www.rfc-editor.org/rfc/rfc9420.html

@silverpill

>CONFIG\_PATH is mentioned in "Installation - Building from source"

Oh derp, so it is. It didn't occur to me that the env var applied to mitractl till I skimmed the source, though in hindsight, that is kind of obvious. Maybe a gentle reminder somewhere in docs/mitractl.md?

@silverpill

Oh thanks for the reply. To reiterate, I do really like mitra, and most of my complaints are more "nice to haves".

I don't have a pressing need for an alternate frontend, my reasoning was "The backend appears to have some notion of follower approval, I wonder if changing the frontend will get that working".

>I think I could add these static files to mitra-web releases as well.

The common deployment probably is a build without any extra configuration, so that would save a step.

Apart from the config file syntax to get SO_PASSCRED pgsql auth to work, the only other gap in the documentation I encountered was that I had to dig through the mitractl source to find the CONFIG_PATH environment variable. But it was easy to find.

Out of all the fediverse server options, @mitra was the least annoying to install on a VPS.

The one stumbling block I hit installing on a RHEL-for-cheap-fucks system, was that since I don't use containers, the documentation's DB auth setup does not work out of the box (postgres at least as packaged in RHEL derivatives use identd and or SO_PASSCRED for authentication).

For others that run into this database_url: postgres://mitra@%2Fvar%2Frun%2Fpostgresql/mitra just works, and the mitra user doesn't need a password.

Pros:

- Skimming the backend code, I didn't find anything that made me sad, and it was well written and readable.
- Installation was mostly painless. I tried misskey at first, but I ran into "install a ts compiler or the frontend won't build". mitra for the most part just worked.
- It was easy enough to disable the cryptocurrency nonsense.

Cons (More like a feature wishlist):

- It appears that while the backend supports "manual follower approval" the frontend does not. I do prefer more control over my social graph. I tried casually to use pleroma-fe with a mitra-backend but that didn't work for me.
- I had to shit up my VPS with node so I can rebuild the frontend. Prebuilt assets would be nice.