search

astro / buzzrelay

Source to relay.fedi.buzz: relay the streaming API of Mastodon instances
https://relay.fedi.buzz
GNU Affero General Public License v3.0
70 stars 9 forks source link

Posts delivered by buzzrelay is blocked by Misskey #4

Open Ninlives opened 1 year ago

Ninlives commented 1 year ago

Problem

Subscribe to buzzrelay on Misskey does not show any posts because they are all blocked by the server with the following error:

failed(UnrecoverableError: skip: signerHost(<hostname/of/buzzrelay>) !== activity.id host(<relayed/instance>)

Findings

Misskey will check if the host of the signature's keyId is equal to the host of the activity id, and activity will be blocked if they do not match: https://github.com/misskey-dev/misskey/blob/e2261b63e9053fb5116dd0ef393f464bf16da190/packages/backend/src/queue/processors/InboxProcessorService.ts#L159

Ninlives commented 1 year ago

Simply replace the id field of the sent activity would fix the problem (I use format!("{}/{}", actor_id, post_url) to construct the id). By the way, all post relayed by buzzrelay appears to be a renote (boost in mastodon) by actor @instance-<host>, is this intended? A little bit annoying because I have to mute @instance-<host> otherwise every post would show up twice in the timeline :(

astro commented 1 year ago

id identifies a post so we cannot modify it or they show up as duplicates, which is what you witnessed.

I wonder if this is this really the part of Misskey that processes posts from relays?

Ninlives commented 1 year ago

They are not duplicates, but Misskey would show both the renote event and the note being renoted in the global timeline, just like how it treats normal renotes, but not suitable for a relay in my opinion (How does Mastodon handle this? I guess the post being boosted is not shown on timeline?)

It is part of the process, the UnrecoverableError appears every time a relayed post arrive.

I'm still a noob in fediverse and my knowledge about ActivityPub is extremely limited so please correct me if I made stupid mistakes again, but according to my understanding of the protocol, id in the Announce activity should identify the Announce itself, not the post being announced. I did not find any direct evidence from the specification, but:

  1. Object Identifier indicates the id should be Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. Here the Announce activity is originated from buzzrelay, and the actor also lives on buzzrelay.
  2. All Create activity in example have different id with the post being created, my understanding is that this applies to Announce activity as well.
astro commented 1 year ago

Now running with 89938a7. Does that improve things? Does that break things?

It doesn't look like I have to actually serve these URLs. So far I'm not getting requests for them.

Ninlives commented 1 year ago

It works fine on my Misskey instance, I hope it does not break other fediverse servers. The relayed posts are showed up as renotes, but this should be fixed by Misskey upstream.