Hello universe! It's been a while ^_^

I had a life transition, been busy with it, didn't have much time for computer work. But the project is very much alive!

@criztovyl is working on federation in GitLab CE. I'm working on Push activities in Vervis, which will be auto-generated from VCS pushes.

The spec documents are still waiting for me to give them lots of love, but here they are. The vocabulary spec is the interesting part right now.

Thx 4 all the ❤

@forgefed @criztovyl :stonks: after due consideration, I now think #ActivityPub *is* kinda a good idea. Keep going, and I'll always help!

P.S. I'm prob writing a paper on this just to finish a stupid task. After that I'm gonna participate normally.

@forgefed @criztovyl but the bad thing is that I can't read #Haskell, and heck I'm still not getting the hang of HTTP signatures. :badstonks: Can anyone explain?

@fakefred sure :) On the fediverse, HTTP sigs are used like this: When one server delivers an activity to another server by doing an HTTP POST to some actor's inbox, it adds a signature to that POST request, placed in an HTTP header. The receiving server verifies the signature, to verify the authenticity of the activity author (i.e. to be sure the actor who sent the activity and the actor specified in the activity are the same one, preventing forging. This is a bit like DKIM or GPG in email.

There's a spec draft of HTTP Signatures that explains how the signature is produced, sent and verified, and there are existing implementations in some programming languages. For prototyping you can do without it, but for "production" stuff and fediverse interoperability, right now it's the de-facto standard for activity sender authentication.

@fr33domlover so the signature is for verifying the identity of the sender, yes? So how is the authenticity check performed? Like, what cryptography are they using?

@fakefred first the signature input is generated, from HTTP headers. Using that input and the signature itself, and the signature key specified, the signature can be verified. The common fediverse standard is to use RSA PKCS1.5 with SHA-256 (a.k.a RSA-SHA256) signatures (I guess because it's an established public-key signature system).

@fr33domlover nice. I like how extensive HTTP can be. :stonks:
i read ForgeFed's upcoming plans... surely a lotta work. I wish i could help with more.

@fakefred there's lots you can help with :) would you like to coordinate with @criztovyl on the forum to do GitLab and Gitea etc. work in parallel in coordination?

I hope to give the specs more attention soon, so that there will be some documentation for how to federate forges in practice.

@fr33domlover Tough chance I'd go to actually develop GitLab or Gitea because learning new languages and their ecosystems takes time; anyway, I'd love to test them :)

@fr33domlover Also, is there any way we can build a "write once, run everywhere™️" piece of software that gets AP & Fed implemented and avoid stuff like "iT's RLy hArD tO iMpLeMeNt AcTiViTyPuB iN gO" show up in gitea's roadmap threads?

@fakefred there's a library named go-fed actually, that implements AP in Go. As to write-once reusable solutions, hmmm it's not a common thing right now, and I'm not aware of ready-to-use options, but here's what I've seen:

- @zplus made a federation server called MCFI, in Python, maybe it can be used for federation of existing forges?
- There's a project named CommonsPub, generic AP server based on Pleroma
- There's an AP server called Tonola intended for experimentation

Making something reusable and languages independent is difficult. Anyway, the basic components you need for an AP implementation:

- System for async delivery of activities, kind of like how forges trigger web hooks. I think Redis is commonly used for async job queues and such.
- Library for parsing and encoding of AP JSON
- Database schemas that support person references being remote uses, e.g. the author of a comment
- Hmm Tusky is weird, I can't see what I'm typing :o

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).