Notices by Aumetra Ⓐ :nonbinary: :good_boy:​ (0x0@corteximplant.com)

@erlend @hongminhee If there is interest, we can totally chat about it. I think there are some nice bridges like napi that offer a nice binding between NodeJS <-> Rust, but I'm not sure about Deno (or if having a Node.js plugin would be good enough?)

@erlend @hongminhee depends on the module. when disabling the easy module, it could totally compile to wasm i think. the easy module depends on rayon to asyncify the cryptography which doesn't play well with wasm (because it spawns threads)

@erlend @hongminhee well, its something we can figure out if there is interest in collaborating on that.
then we can figure out the logistics of packaging these things in something that can be distributed well

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

Mhmm.. making some tea in the new mug :corteximplant:

@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:)

@choyer @fediversenews Honestly, defederation is fine, good even.

It's a vital tool in keeping communities safe and healthy; especially the most vulnerable in the communities.

If you think this feature is not really useful or harmful even, you probably aren't part of the groups this feature intends to protect.

There are enough instances that don't block anyone ever and leave it up to the user to block the people they "disagree" with.
Instances with this laissez-faire approach to moderation don't have a lot of visibility because joinmastodon.org, for example, has a server covenant that these servers aren't particularly compatible with, let's put it that way.