feat: add mastodon style relays #109
Conversation
| * "id": "https://client.example/6ae15297", | ||
| * "type": "Follow", | ||
| * "actor": "https://client.example/actor", | ||
| * "object": "https://www.w3.org/ns/activitystreams#Public" |
There was a problem hiding this comment.
He the relay should actually understand both, as they're semantically the same, I'd file a bug with the relay implementation
There was a problem hiding this comment.
I am not sure about this.
The object of the Follow request MUST be the fully expanded URI of the Public pseudo-collection (https://www.w3.org/ns/activitystreams#Public).
As far as I understand, but you can correct me:
https://www.w3.org/ns/activitystreams#Publicfully expandedas:publicnot fully expanded
Imagine building a new relay software: I would look at the spec and see that the object property should be equal to https://www.w3.org/ns/activitystreams#Public. So I would just check for this. This is why I think using https://www.w3.org/ns/activitystreams#Public would make it more compatible with more relay softwares. But at this point I only tested one software.
|
Would probably also make sense to abstract out functions for determining "should this be relayed" and "forward this to a relay" |
|
@dahlia can you look into the verify key issue? You can use |
It seems that Fedify fails to parse its public key is because it's encoded in PEM-PKCS#1 whereas Fedify expects PEM-SPKI, which is much more common in the fediverse (as far as I know). Hmm… should Fedify accept PEM-PKCS#1 as well? 🤔 |
I think, yes 🙃 As far as I know, it is not against the spec. Even though I think this is not the only issue with the tested relay software. But this would bring it one step further. I naively tried to patch fedify yesterday, but what I did was 100% wrong 🥲 |
|
Now Fedify accepts PEM-PKCS#1-encoded RSA public keys (besides PEM-SPKI-encoded ones), and it will be shipped in Fedify v1.5.0, the next minor release. Until then, you could give it a try Fedify v1.5.0-dev.654+b5166915, which is an unstable release. |
|
The next issue I found. This is the http signature: The keyId is set to I am not sure if this is also an incorrect behavior of fedify. https://swicg.github.io/activitypub-http-signature/#how-to-obtain-a-signature-s-public-key
Maybe the spec is meant this way: Fetch the key from keyId. If keyId specifies a specific key, use it. Otherwise, use first. Damn, activity pub is harder than I could have ever imagined 😁 Respect for implementing fedify. |
Whether it is Fedify's fault or not, Fedify should behave as liberal as possible in accordance with the robustness principle— |
|
Fedify now does the best to find the appropriate public key. If there is no fragment in |
In this PR I try to add mastodon style relays conforming to FEP-ae0c.
Todos
@[email protected], but this doesn't work for FediBuzz. Sadly the spec isn't clear how to get the relay server actor from the inbox url. Most relay softwares simply have@[email protected], but not softwares with custom inboxes for different feeds. Do we actually need the relay server actor? I may only added this, to fill out the id property ofRecipientwhen callingsendActivity. Maybe the inbox url is enough?fedify lookup https://relay.toot.io/actor -d---->Failed to parse JSON-LD document: TypeError: Invalid PEM-SPKI format.Failed to verify the request's HTTP SignaturesandFailed to verify; key 'https://relay.intahnet.co.uk/actor' returned an invalid object.fedify lookup https://relay.intahnet.co.uk/actor -dshowsFailed to parse JSON-LD document: TypeError: Invalid PEM-SPKI format.disabledandenabledstate for relays to temporary disable a relay. Mastodon has this feature.https://www.w3.org/ns/activitystreams#Publictoas:public