Programming Languages to Implement an SDK For

[soatok]

I want to try to balance two competing desires here:

1. To not personally be a single point of failure for the entire ecosystem
2. To make it easier for Fediverse software to integrate with the PKD

To that end, I've made a loose prioritized list of programming languages that I believe are worth delivering an SDK for communicating with the Public Key Directory.

Languages Being Considered

1. TypeScript - Misskey, PeerTube, Micro.blog, etc. (Also for browser extensions)
2. Ruby - Mastodon (and its many forks), etc.
3. PHP - Pixelfed, Friendica, etc.
4. Elixir - Pleroma, Mobilizon, Akkoma, etc.
5. Python - Bridgy, Bookworm
6. Rust - Lemmy
7. Go - WriteFreely

What I need from you?

1. Are there any languages not in this list that must be?
2. Are there any languages in this list that are not a high priority for us to build an SDK for other Fediverse developers to use?
   • Being excluded doesn't mean it won't exist, just that I won't be burdened with writing it.

[BenBE]

I think adding C to the list might be worth a thought, as this would allow people to get bindings for many other languages using the usual FFI binding approach their language of choice provides. This would also allow for writing the core of the bindings once and provide a common ground for at least PHP (PECL) and Python (pybind).

In the end, the question boils down to what the SDK should encompass: if this is mostly "here's some abstraction of all the REST API calls (let me curl that for you), or if this does heavy lifting for all the state (I know what you key'd last summer) too …

[soatok]

I think that's a good idea for the community, but I am not writing C.

Rust? Sure.

C? I do not trust myself to write C or C++ code that is secure.

[aumetra]

I think that's a good idea for the community, but I am not writing C

C bindings to a Rust library sounds like it could be sufficient for that case?

Would follow the precedents set by Python's cryptography package and by a large chunk of Matrix's crypto libraries. Write the crypto in Rust, bind to it via C FFI.

[Waelwindows]

I think that's a good idea for the community, but I am not writing C

C bindings to a Rust library sounds like it could be sufficient for that case?

I think writing a core Rust library for the SDKs and exposing bindings to it is the best approach for this project. There's prior art for this, see matrix-rust-sdk.

Doing this approach makes it easy for auditing as you just have to audit the source implementation in Rust, instead of the $n$ language implementations.

Using something like uniffi would immediately give us bindings for TypeScript/JavaScript, Python, Ruby and Go.
Furthermore, we can generate Dart, Kotlin and Swift for the client side as well!

This'll leave Elixir and PHP. Handling Elixir would re-writing bindings with something like rustler and similarly for PHP with ext-php-rs

I am willing to work on the above. However, I am not an expert cryptographer and as such will have to leave the side-channel analysis and such to y'alls expert judgement ^^

[Waelwindows]

I started working on it!
You can see my work at https://github.com/Waelwindows/pkd-client

[soatok]

Great. I'll focus on the PHP client, then: https://github.com/fedi-e2ee/pkd-client-php

[soatok]

https://github.com/fedi-e2ee/pkd-server-php - new server implementation

[Waelwindows]

Hi, I saw your recent blogpost. Thanks for the shoutout!

I'd like to apologize for not being as on-hands on this project as I would've liked. I recently got hired and my day job took a lot of my free time. Despite this, I won't stop working on this project. I think it's even more important to get this working soon since Fedi servers like Mastodon are starting to take Fedi-E2EE seriously.

On a brighter note, I managed to get PoC uniffi bindings for Python working. The cool thing about it is it's built using Nix in CI, which means the build and bindings are reproducible. This makes binary transparency easier!
Now what's left is implementing the cryptogrphy itself. I'm structuring the code so that it's easy to make a server as well, not that I have the bandwidth to work on that right now. I would like to ask for some code review once I get that done (I'm not a professional cryptographer after all).

While working ony my implementation, I realized that we should probably restructure some parts of the specification (e.g. the encodings) so it's more amicable to duvet. Specifically, we should split every requirement so it's easier to report. And while we're at it, remove some ambiguity in the spec (e.g. should an implementation ignore the signature or reject if a signature is present on a RevokeKeyThirdParty request)

[soatok]

Nice! Don't worry too much, I've been rapidly trying to get a stable v0.1 out just so there's something to test clients against. Now I'm taking a bit of a break before I iron out bugs and missing features.