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 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.
@0x0 I think the best way to start using Ed25519 is FEP-8b32, because objects can be signed in a way that doesn't break backwards compatibility No need to wait for a response from Mastodon team.
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:
This is actually pissing me off. And the maintainers are just ghosting the issue that asks for updating the HTTP signatures Implementation
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.
@0x0 FEP-521a: Representing actor's public keys.
It's implemented in Mitra (my actor has both RSA and Ed25519 keys), but there are no other implementations I'm aware of.
@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
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.