Egregoros · Phoenix Framework

Post

Remote status

Context

rose

Okay I need help with pleroma federation
for some reason a bunch of instances just don't federate properly anymore, or seemingly only federate one way

looking at the logs I see a bunch of stuff like this
pleroma: Failed-signature inbox retry rejected reason=:invalid_signature payload_actor="https://instance.url/users/username" signature_actor="https://instance.url/users/username" activity_id="https://instance.url/activities/uuid" type="Like" request_path="/inbox"

I don't recall changing anything about signing so I have no idea what the issue may be

edit: okay I realize I won't see replies so uh ping @rose when you do reply

Phantasm

@phnt@fluffytail.org remote

@rose It's Mastodon doing its weird thing with relaying posts to other instances. The actor in the signature is mismatched with the activity, because Mastodon has to resign the request with a new key and fallback to verifying authenticity with LD Signatures which Pleroma doesn't support. You can ignore these warnings and blame Mastodon for not having an internal flag to stop spamming remote instances with requests that will always fail.

What's more likely is that you had 410 HTTP response codes on this instance when it went dead, because Misskey craps out when that happens without doing that, and now Misskey treats this instance as dead.

Phantasm

@phnt@fluffytail.org remote

@rose Actually no, the error would say actor mismatch. This is something different...

Phantasm

@phnt@fluffytail.org remote

@rose @rose Either the signature is wrong (doesn't validate) even after a key refetch or the signature has an incorrect keyID not pointing to a valid actor. FWIW I have none of these in my logs.

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose yeah that's the thing, I don't remember doing anything, rn I'm running an upgrade to see if that fixes it but idk i'm not really confident lol

Phantasm

@phnt@fluffytail.org remote

@rose @rose Is it just one server software or more. Is there something in common?

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose no it seems to be random, i can see pleroma, akkoma and mastodon instances having issues, but also pleroma, akkom and mastodon instances still federating
like it's not that my whole timeline isn't updating, there are still a couple of accounts that federate normally

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose yeah still nothing after an upgrade
let me try rebooting the server ig
do you think it could be a timezone thing? for some reason that keeps resetting

Phantasm

@phnt@fluffytail.org remote

@rose @rose Time shouldn't matter I think, the keys are supposed to be semi-permanent. It's weird that signatures just fail like that, the actor is known already, because it is logged, and the crypto part is handled by Erlang.

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose yeah that's what confuses me as well
doesn't seem to be fixed after a reboot either
super tempted to just call it quits with this instance and start a new one lmao

Phantasm

@phnt@fluffytail.org remote

@rose @rose I mean, time would matter for TLS which is used for the key fetches, but that wouldn't fail this way and you would have a bunch of Erlang SSL warnings logged elsewhere. And being hours behind would have almost non-existent impact anyway.

Phantasm

@phnt@fluffytail.org remote

@rose @rose Maybe give a Pleroma OTP release or source install a try. I really don't know.

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose some instances are starting to come in lmao?? average activitypub moment i guess

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose is there some way to force fetch keys or something/

Replying to @rose@brain.worm.pink

Phantasm

@phnt@fluffytail.org remote

@rose @rose The retry worker should do that on its own, but if you want to do it manually, you can do it via IEx access. pleroma_ctl remote as the pleroma user for OTP releases, or starting Pleroma with elixir --name pleroma@127.0.0.1 --erl '-kernel inet_dist_listen_min 9001 inet_dist_listen_max 9001 inet_dist_use_interface {127,0,0,1}' -S mix phx.server and then running iex --remsh pleroma@127.0.0.1 --name console@127.0.0.1 for source installs. Pressing Ctrl-C twice will get you out of IEx.

Pleroma.User.fetch_by_nickname("@classic@mention.syntax")

Pleroma.User.fetch_by_ap_id("https://example.com/user/coolname")

Those will force-refetch the user and rewrite the cache.

Replies

Replying to @phnt@fluffytail.org

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose hm `pleroma_ctl remote` doesn't work for me

Replying to @rose@brain.worm.pink

Phantasm

@phnt@fluffytail.org remote

@rose @rose Still running NixOS on the server, might be something to do with that possibly.

Replying to @phnt@fluffytail.org

Rose ☭

@rose@brain.worm.pink remote

@phnt @rose nah it's gentoo now, it's `pleroma_ctl user remote` apparently?

Replying to @rose@brain.worm.pink

Phantasm

@phnt@fluffytail.org remote

@rose @rose Sorry, I'm dumb. It's pleroma remote

Replying to @phnt@fluffytail.org

Kirby

@kirby@freerobuxextremist.com remote

@phnt @rose @rose alternatively `echo pleroma_console=YES > /etc/conf.d/pleroma` will do if you're using the pleroma openrc service to manage pleroma. which you probably are

Replying to @kirby@freerobuxextremist.com

Rose ☭

@rose@brain.worm.pink remote

@kirby @phnt @rose okay yeah this one causes it to crash lmao
i think i'll have it naturally retry

Replying to @rose@brain.worm.pink

Phantasm

@phnt@fluffytail.org remote

@rose @kirby @rose That's for source installs...