Notices by 0x0 :nonbinary: :netscape_1: (0x0@corteximplant.com)

also im finally working on the wasm mrf FEP. it's been way too long.

#fedidev

@silverpill is there an FEP about multiple keys attached to an actor? I skimmed over the index but haven't seen one?

Because if that's the case, that might be something to put on the roadmap since I personally very much prefer Ed25519 over damn RSA

Also Kitsune is probably gonna use nightly from now on. Because "async fn in trait", some improved diesel diagnostics, and some better SIMD performance

I'm hoping to make Kitsune even faster. Just because.

Also Dalek Cryptography's curve25519 operations have nice parallel formulas using nightly stdsimd. Meaning if I finally get to porting the HTTP signatures over to pure Rust cryptography, that could give some nice boost in performance.

Well, in the edge case that someone actually uses Ed25519, which nobody does because Mastodon doesn't support it for some god damn reason.

So we are stuck with the slow and fragile RSA system and gigantic keys just because.

This is actually pissing me off. And the maintainers are just ghosting the issue that asks for updating the HTTP signatures Implementation

Hah, the last comment on the issue is mine asking whether they'd be open to at least adding Ed25519 support. From around 6 months ago. :nervous:

The best proof that ActivityPub doesn't need JSON-LD: I have written three or so implementations and I still got no real clue how the fuck JSON-LD works

@silverpill @cmdrmoto Yeah, true. Per definition a blockchain has nothing to do with a currency, it's just an append-only database following some kind of consensus.
I'm just thinking about the scalability implications of this very append-only system.

Scalability from a disk-space perspective. It just grows and grows without any way to really "stop" the size.

With time this will centralise to some few nodes that have the financial capacity to buy more and more disks.

@cmdrmoto I really appreciate the feedback, and I agree with your care towards authentication systems. They are inherently complex and there is a good reason for it.

Don't be discouraged by my, let's say, negativity towards cryptocurrency.
My intention is to design, at least the ActivityPub portion, to not care about the DID used.

It just has to be able to somehow verify the proof (i.e. the signature) defined in FEP-c390 + some cryptographic authentication challenge.

The keys used to sign the proof/authentication challenge have to either be the key of the identity itself or have the necessary capabilities delegated to it.

Even more thoughts about potential nomadic identities.
Featuring Ed25519, UCAN, and DHTs
(it's 1AM, I might have overlooked some stuff)

https://aumetra.xyz/posts/nomad-id-first-steps

Some notes about nomadic identities, mostly on how to maybe achieve a system where I can log into a2.example.com with an account on a1.example.com, using identity proofs

https://aumetra.xyz/posts/fediverse-nomadic-identities

(not a masterpiece but readable and somewhat coherent :blobfoxcoffee:)