yukimochi / activity-relay

Yet another powerful customizable ActivityPub relay server written in Go.

Activity Relay Server

Yet another powerful customizable ActivityPub relay server written in Go.

Packages

• github.com/yukimochi/Activity-Relay
• github.com/yukimochi/Activity-Relay/api
• github.com/yukimochi/Activity-Relay/deliver
• github.com/yukimochi/Activity-Relay/control
• github.com/yukimochi/Activity-Relay/models

Requirements

• Redis

Run

API Server

relay --config /path/to/config.yml server

Job Worker

relay --config /path/to/config.yml worker

CLI Management Utility

relay --config /path/to/config.yml control

Config

YAML Format

ACTOR_PEM: /var/lib/relay/actor.pem
REDIS_URL: redis://redis:6379

RELAY_BIND: 0.0.0.0:8080
RELAY_DOMAIN: relay.toot.yukimochi.jp
RELAY_SERVICENAME: YUKIMOCHI Toot Relay Service
JOB_CONCURRENCY: 50
# RELAY_SUMMARY: |

# RELAY_ICON: https://
# RELAY_IMAGE: https://

Environment Variable

Optional : When config file not exist, use environment variables.

• ACTOR_PEM
• REDIS_URL
• RELAY_BIND
• RELAY_DOMAIN
• RELAY_SERVICENAME
• JOB_CONCURRENCY
• RELAY_SUMMARY
• RELAY_ICON
• RELAY_IMAGE

How to Use Relay (for Relay Customers)

Mastodon, Misskey and their forks

Subscribe this inbox https://<your-relay-server-address>/inbox

Pleroma and their forks

Follow this actor https://<your-relay-server-address>/actor

Document

See GitHub wiki to build / install / control relay.

License

GNU AFFERO GENERAL PUBLIC LICENSE

Project Sponsors

Thank you for your support!

Monthly Donation

• Patreon
• pixivFANBOX
• fantia

My Donor List

Open Source Support Program

• JetBrains for Open Source

activity-relay's Issues

[feature request] Keep track of last successful post to subscribed instances

Hello!

I apologise if this is already present. I was thinking it would be useful to store the timestamp of when a relay last accepted a relayed message.

I couldn't find any way to do this from the data stored in Redis, but I might have missed something.

This would be very useful to clean up dead instances that didn't unsubscribe prior to shutting down.

Akkoma instances unable to subscribe

I'm not sure if this is an Akkoma bug, or a bug with Activity-Relay, but I'm seeing issues with Akkoma users being unable to subscribe to my Activity-Relay instance.

I setup a test Akkoma instance to try and figure out what was going on, and found that it appears to be due to the /actor endpoint of Activity-Relay having a type of "Service". Modifying this to be type: "Application" appears to allow Akkoma instances to subscribe successfully.

Please let me know if this is an Akkoma bug, and I will open an issue with Akkoma instead. I couldn't find any guidance on what type it should be in the activitypub spec (https://www.w3.org/TR/activitypub).

Steps to Reproduce:

• Attempt to subscribe to Activity-Relay from an Akkoma instance.
• Observe that the subscription fails with Akkoma either outright rejecting the follow attempt with:

15:39:55.256 [error] Could not fetch user https://relay.intahnet.co.uk/actor, {nil, {:error, "Not a user"}}

15:39:55.256 [error] error: :not_found
Error while following https://relay.intahnet.co.uk/actor: :not_found

or repeatedly requesting /actor multiple times a second.

• Inspect the Activity-Relay /actor endpoint declaration and note the type: "Service" designation.

Expected Behavior:

• Akkoma instances should be able to successfully subscribe to Activity-Relay as it's a fork of Pleroma.

Actual Behavior:

• Due to the /actor endpoint being categorized as type: "Service" in Activity-Relay's implementation, Akkoma instances are unable to subscribe. Either it outright rejects the follow attempt, or hammers /actor multiple times per second.

Workaround:

• Modifying the type declaration of the /actor endpoint in Activity-Relay to type: "Application" enables successful subscription from Akkoma instances:

# modified /actor endpoint
~ $ curl -s  https://relay.intahnet.co.uk/actor | jq | grep type
  "type": "Application",
  
# Observe successful subscription from Akkoma
~ $ MIX_ENV=prod mix pleroma.relay follow https://relay.intahnet.co.uk/actor
....
16:32:11.487 [info] relay: followed instance: https://relay.intahnet.co.uk/actor; id=https://akkoma.intahnet.co.uk/activities/33a2dd78-6852-4af2-8def-f085e5d0733d

Panics since upgrading to 2.0.0

Hello!

I'm seeing a lot of panics since upgrading to 2.0.0. I don't know how to debug it. Is this a bug? or something wrong with my setup?

2023/03/27 13:25:01 http: panic serving 10.233.73.235:60464: interface conversion: interface {} is string, not map[string]interface {}
goroutine 1514315 [running]:
net/http.(*conn).serve.func1()
	/usr/local/go/src/net/http/server.go:1854 +0xbf
panic({0xb26200, 0xc000976a20})
	/usr/local/go/src/runtime/panic.go:890 +0x263
github.com/yukimochi/Activity-Relay/models.(*Activity).UnwrapInnerActivity(0xc000000c00?)
	/Activity-Relay/models/models.go:149 +0x39c
github.com/yukimochi/Activity-Relay/api.executeRelayActivity(0xc0008e3f80, 0xc000000c00, {0xc000949880, 0x307, 0x380})
	/Activity-Relay/api/resolver.go:334 +0x197
github.com/yukimochi/Activity-Relay/api.handleInbox({0xcbfa10, 0xc0008f6fc0}, 0x0?, 0x1?)
	/Activity-Relay/api/handle.go:111 +0x1f0
github.com/yukimochi/Activity-Relay/api.handlersRegister.func1({0xcbfa10?, 0xc0008f6fc0?}, 0xffffffffffffffff?)
	/Activity-Relay/api/api.go:78 +0x2a
net/http.HandlerFunc.ServeHTTP(0xc0008f6fc0?, {0xcbfa10?, 0xc0008f6fc0?}, 0xbdc09d?)
	/usr/local/go/src/net/http/server.go:2122 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0xcbfa10, 0xc0008f6fc0}, 0xc00019ec00)
	/usr/local/go/src/net/http/server.go:2500 +0x149
net/http.serverHandler.ServeHTTP({0xcbe028?}, {0xcbfa10, 0xc0008f6fc0}, 0xc00019ec00)
	/usr/local/go/src/net/http/server.go:2936 +0x316
net/http.(*conn).serve(0xc0007b63f0, {0xcbfd88, 0xc00033e2d0})
	/usr/local/go/src/net/http/server.go:1995 +0x612
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:3089 +0x5ed

Error 405. What am I missing?

This is perhaps a dumb question, but do I need to run this on the same server as a Mastodon instance?

There's nothing in the docs here to suggest I do, but despite my best efforts I can not get the Relay to work. I am almost there. if I goto /actor I get a json response. /inbox gives me an HTML 405 error

I can add it as a relay on a mastodon instance, and it then shows as "waiting for approval". When I check the relay and ask for a list, the mastodon instance is listed

It made me wonder if the Relay needs mastodon configured on the server too.

OR am I missing something else

relay stays stuck as pending

Hi, I've tried adding the public relay to my misskey instance (using https://relay.toot.yukimochi.jp/inbox), but it seems to stay stuck as pending, is it normal or not?

DockerDockerは起動できますが、使えません。

こんばんは、私はバインディングアドレスを127.1.0.1または0.0.0.0に設定してみましたが、ポートの占有を確認したところ、8051ポートは使用されていませんでした。中継ポートは8051に設定されています。標準の8080ポートを使ってみましたが、使えませんでした。助けてほしいです。

runtime error on server - v0.2.4

Running on https://neighbours.aus.social/ - Latest release v0.2.4

server_1      | 2020/01/29 03:33:01 http: panic serving 172.26.0.1:44626: runtime error: invalid memory address or nil pointer dereference
server_1      | goroutine 285 [running]:
server_1      | net/http.(*conn).serve.func1(0xc000136e60)
server_1      | 	/usr/local/go/src/net/http/server.go:1767 +0x139
server_1      | panic(0xed5640, 0x19a7910)
server_1      | 	/usr/local/go/src/runtime/panic.go:679 +0x1b2
server_1      | github.com/yukimochi/Activity-Relay/KeyLoader.ReadPublicKeyRSAfromString(0x0, 0x0, 0x27, 0xc000084180, 0x5d)
server_1      | 	/Activity-Relay/KeyLoader/keyloader.go:28 +0x69
server_1      | main.decodeActivity(0xc0000eb500, 0x203000, 0x203000, 0x203000, 0x203000, 0x200, 0xe, 0x203000)
server_1      | 	/Activity-Relay/decode.go:35 +0x3f4
server_1      | main.handleInbox(0x12af0e0, 0xc00037e0e0, 0xc0000eb500, 0x105b840)
server_1      | 	/Activity-Relay/handle.go:174 +0xbb
server_1      | main.main.func1(0x12af0e0, 0xc00037e0e0, 0xc0000eb500)
server_1      | 	/Activity-Relay/main.go:102 +0x4b
server_1      | net/http.HandlerFunc.ServeHTTP(0x105b858, 0x12af0e0, 0xc00037e0e0, 0xc0000eb500)
server_1      | 	/usr/local/go/src/net/http/server.go:2007 +0x44
server_1      | net/http.(*ServeMux).ServeHTTP(0x19bfda0, 0x12af0e0, 0xc00037e0e0, 0xc0000eb500)
server_1      | 	/usr/local/go/src/net/http/server.go:2387 +0x1bd
server_1      | net/http.serverHandler.ServeHTTP(0xc00037e000, 0x12af0e0, 0xc00037e0e0, 0xc0000eb500)
server_1      | 	/usr/local/go/src/net/http/server.go:2802 +0xa4
server_1      | net/http.(*conn).serve(0xc000136e60, 0x12b3320, 0xc0000c79c0)
server_1      | 	/usr/local/go/src/net/http/server.go:1890 +0x875
server_1      | created by net/http.(*Server).Serve
server_1      | 	/usr/local/go/src/net/http/server.go:2928 +0x384

Use viper as Configuration manager.

Reference: https://github.com/spf13/viper

Error connecting to redis over TLS

I'm using digital ocean and their redis server requires TLS. I receive an EOF error from the worker when using a rediss:// URL. Is this supported?

Endpoint to get a list of connected instances (subscribers)?

I checked out /nodeinfo/2.1 but it only return the number of subscribers.

Is there a way to query "relay control domain list" from the web?

I'm trying to create a frontend for Activity-Relay, that's why I would need this.

ar-cli domain unfollow resulting in worker errors

shlee@localhost:~/Activity-Relay$ docker-compose exec server ar-cli domain unfollow m.semicharmed.net
Config file is not exists. Use environment variables.
Unfollow [m.semicharmed.net]
shlee@localhost:~/Activity-Relay$ docker-compose exec server ar-cli domain unfollow cyzed.com
Config file is not exists. Use environment variables.
Unfollow [cyzed.com]
shlee@localhost:~/Activity-Relay$ docker-compose exec server ar-cli domain unfollow photodon.org
Config file is not exists. Use environment variables.
Unfollow [photodon.org]

Running the commands above results in a lot of errors in the worker.

Restarting the docker-compose seems to resolve some of the errors, but some remain.

Unsure how to follow instances

I'm sorry but I'm not sure howto follow servers using your software. I want to add other servers to the relay that I can follow it with my own instance but the documentation doesn't seem to describe howto do that. I may have missed it and I would love to be corrected.

Thanks you in advance

High response time for some POST requests

Hello!

I'm seeking general advice on resolving some high response time issues with my relay.

I'm seeing a lot of POST requests which are timing out on the client side.

I believe Mastodon's default timeout is 10 seconds, and for some reason, on my relay I can see when a "POST /inbox" request comes in, sometimes it takes over 10 seconds to respond.

This is only for some requests, the majority are processed under 200 ms.

I don't think the ActivityRelay server is CPU bound, as the ActivityRelay server doesn't seem to be consuming very much CPU.

I was wondering if you might know options for tracking down the bottleneck and why some requests have extremely high response times, whereas others are extremely quick?

Use cobra as CLI Interface framework.

HTTP署名の Actor とリモート Actor が混在して扱われている。

署名に使われた Actor と 投稿の Actor が異なる際に予期しない動作をする。

more durable storage?

Would it be possible to add support for a more durable storage?

I just had a crash where all data is lost in redis. No OOM, all systems are still running (e.g. no restarts) but basically empty database. The unfortunate thing is that clients do not know that they need to "re-register", which is why redis is not so ideal, as you can not rely on it as source of truth.

Relay service exiting due to ACTOR_PEM parsing error.

Currently receiving an error when trying to run relay-api and relay-worker service.

Steps to reproduce

• go version go1.18.1 linux/amd64, ubuntu v22.04
• Clone v1.1.1 and build binary from source.
• Follow steps listed here: https://github.com/yukimochi/Activity-Relay/wiki/01.-Install#linux-service
• tail /var/log/syslog

Logs:

Nov 15 04:58:08 pc-linux relay[8578]: RELAY_ICON: INVALID OR EMPTY. THIS COLUMN IS DISABLED.
Nov 15 04:58:08 pc-linux relay[8578]: RELAY_IMAGE: INVALID OR EMPTY. THIS COLUMN IS DISABLED.
Nov 15 04:58:08 pc-linux relay[8578]: ACTOR_PEM: x509: failed to parse private key (use ParsePKCS8PrivateKey instead for this key format)
Nov 15 04:58:08 pc-linux systemd[1]: relay-api.service: Main process exited, code=exited, status=1/FAILURE
Nov 15 04:58:08 pc-linux systemd[1]: relay-api.service: Failed with result 'exit-code'.
Nov 15 04:58:08 pc-linux relay[8583]: RELAY_ICON: INVALID OR EMPTY. THIS COLUMN IS DISABLED.
Nov 15 04:58:08 pc-linux relay[8583]: RELAY_IMAGE: INVALID OR EMPTY. THIS COLUMN IS DISABLED.
Nov 15 04:58:08 pc-linux relay[8583]: ACTOR_PEM: x509: failed to parse private key (use ParsePKCS8PrivateKey instead for this key format)
Nov 15 04:58:08 pc-linux systemd[1]: relay-worker.service: Main process exited, code=exited, status=1/FAILURE
Nov 15 04:58:08 pc-linux systemd[1]: relay-worker.service: Failed with result 'exit-code'.

Pleromaでのエラー

pleromaでリレーを登録時に

ww:xx:yy.zzz [error] Follower/Following counter update for https://relay.toot.yukimochi.jp/actor failed.
{:error, "id must be a string"}

と出てリレーが機能しない

ActivityPub Proxying and Trusted Proxy import and re-republish.

リレーを多段構成可能にして、特殊な機能を実装したリレーと汎用のリレーで投稿を共有できるようにする。

Prevent redundant redis access.

Is there a public URL where people can see which servers are being relayed?

I'd like to be able to send that to potential users.

activity posts larger then 3163 bytes fail (HTTP error 400)

All posts that are larger then 3163 bytes (bodylength) fail. The Activity-relay return HTTP error 400.

After inspection of the code, the issue seems to be in api/decode.go, function "decodeActivity"
If the body length is larger then 3163 octets, "request.Body.Read(body)" returns invalid data.

This is part of trouble-shooting code to print "body":

Note all the "0"'s at the end!

    // Verify Digest
    givenDigest := request.Header.Get("Digest")
    hash := sha256.New()
    hash.Write(body)
    b := hash.Sum(nil)
    calculatedDigest := "SHA-256=" + base64.StdEncoding.EncodeToString(b)

    fmt.Println(givenDigest);
    fmt.Println(calculatedDigest);
    fmt.Println(body);
    if givenDigest != calculatedDigest {
            return nil, nil, nil, errors.New("Digest header is mismatch")
    }

"""
server_1 | SHA-256=iQgJybiKRRWPym5HPOfE/P942FUufBAymJk/WAzrUeQ=
server_1 | SHA-256=WV8mIdNvchFafSwclH0995/n9lNncWYD8mKeXMzfIUc=
server_1 | [123 34 64 99 111 110 116 101 120 116 34 58 91 34 104 116 116 112 115 58 47 47 119 119 119 46 119 51 46 111 114 103 47 110 115 47 97 99 116 105 118 105 116 121 115 116 114 101 97 109 115 34 44 34 104 116 116 112 115 58 47 47 119 51 105 100 46 111 114 103 47 115 101 99 117 114 105 116 121 47 118 49 34 44 123 34 109 97 110 117 97 108 108 121 65 112 112 114 111 118 101 115 70 111 108 108 111 119 101 114 115 34 58 34 97 115 58 109 97 110 117 97 108 108 121 65 112 112 114 111 118 101 115 70 111 108 108 111 119 101 114 115 34 44 34 116 111 111 116 34 58 34 104 116 116 112 58 47 47 106 111 105 110 109 97 115 116 111 100 111 110 46 111 114 103 47 110 115 35 34 44 34 102 101 97 116 117 114 101 100 34 58 123 34 64 105 100 34 58 34 116 111 111 116 58 102 101 97 116 117 114 101 100 34 44 34 64 116 121 112 101 34 58 34 64 105 100 34 125 44 34 102 101 97 116 117 114 101 100 84 97 103 115 34 58 123 34 64 105 100 34 58 34 116 111 111 116 58 102 101 97 116 117 114 101 100 84 97 103 115 34 44 34 64 116 121 112 101 34 58 34 64 105 100 34 125 44 34 97 108 115 111 75 110 111 119 110 65 115 34 58 123 34 64 105 100 34 58 34 97 115 58 97 108 115 111 75 110 111 119 110 65 115 34 44 34 64 116 121 112 101 34 58 34 64 105 100 34 125 44 34 109 111 118 101 100 84 111 34 58 123 34 64 105 100 34 58 34 97 115 58 109 111 118 101 100 84 111 34 44 34 64 116 121 112 101 34 58 34 64 105 100 34 125 44 34 115 99 104 101 109 97 34 58 34 104 116 116 112 58 47 47 115 99 104 101 109 97 46 111 114 103 35 34 44 34 80 114 111 112 101 114 116 121 86 97 108 117 101 34 58 34 115 99 104 101 109 97 58 80 114 111 112 101 114 116 121 86 97 108 117 101 34 44 34 118 97 108 117 101 34 58 34 115 99 104 101 109 97 58 118 97 108 117 101 34 44 34 100 105 115 99 111 118 101 114 97 98 108 101 34 58 34 116 111 111 116 58 100 105 115 99 111 118 101 114 97 98 108 101 34 44 34 68 101 118 105 99 101 34 58 34 116 111 111 116 58 68 101 118 105 99 101 34 44 34 69 100 50 53 53 49 57 83 105 103 110 97 116 117 114 101 34 58 34 116 111 111 116 58 69 100 50 53 53 49 57 83 105 103 110 97 116 117 114 101 34 44 34 69 100 50 53 53 49 57 75 101 121 34 58 34 116 111 111 116 58 69 100 50 53 53 49 57 75 101 121 34 44 34 67 117 114 118 101 50 53 53 49 57 75 101 121 34 58 34 116 111 111 116 58 67 117 114 118 101 50 53 53 49 57 75 101 121 34 44 34 69 110 99 114 121 112 116 101 100 77 101 115 115 97 103 101 34 58 34 116 111 111 116 58 69 110 99 114 121 112 116 101 100 77 101 115 115 97 103 101 34 44 34 112 117 98 108 105 99 75 101 121 66 97 115 101 54 52 34 58 34 116 111 111 116 58 112 117 98 108 105 99 75 101 121 66 97 115 101 54 52 34 44 34 100 101 118 105 99 101 73 100 34 58 34 116 111 111 116 58 100 101 118 105 99 101 73 100 34 44 34 99 108 97 105 109 34 58 123 34 64 116 121 112 101 34 58 34 64 105 100 34 44 34 64 105 100 34 58 34 116 111 111 116 58 99 108 97 105 109 34 125 44 34 102 105 110 103 101 114 112 114 105 110 116 75 101 121 34 58 123 34 64 116 121 112 101 34 58 34 64 105 100 34 44 34 64 105 100 34 58 34 116 111 111 116 58 102 105 110 103 101 114 112 114 105 110 116 75 101 121 34 125 44 34 105 100 101 110 116 105 116 121 75 101 121 34 58 123 34 64 116 121 112 101 34 58 34 64 105 100 34 44 34 64 105 100 34 58 34 116 111 111 116 58 105 100 101 110 116 105 116 121 75 101 121 34 125 44 34 100 101 118 105 99 101 115 34 58 123 34 64 116 121 112 101 34 58 34 64 105 100 34 44 34 64 105 100 34 58 34 116 111 111 116 58 100 101 118 105 99 101 115 34 125 44 34 109 101 115 115 97 103 101 70 114 97 110 107 105 110 103 34 58 34 116 111 111 116 58 109 101 115 115 97 103 101 70 114 97 110 107 105 110 103 34 44 34 109 101 115 115 97 103 101 84 121 112 101 34 58 34 116 111 111 116 58 109 101 115 115 97 103 101 84 121 112 101 34 44 34 99 105 112 104 101 114 84 101 120 116 34 58 34 116 111 111 116 58 99 105 112 104 101 114 84 101 120 116 34 44 34 115 117 115 112 101 110 100 101 100 34 58 34 116 111 111 116 58 115 117 115 112 101 110 100 101 100 34 44 34 102 111 99 97 108 80 111 105 110 116 34 58 123 34 64 99 111 110 116 97 105 110 101 114 34 58 34 64 108 105 115 116 34 44 34 64 105 100 34 58 34 116 111 111 116 58 102 111 99 97 108 80 111 105 110 116 34 125 125 93 44 34 105 100 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 35 117 112 100 97 116 101 115 47 49 54 54 56 57 53 53 48 48 53 34 44 34 116 121 112 101 34 58 34 85 112 100 97 116 101 34 44 34 97 99 116 111 114 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 34 44 34 116 111 34 58 91 34 104 116 116 112 115 58 47 47 119 119 119 46 119 51 46 111 114 103 47 110 115 47 97 99 116 105 118 105 116 121 115 116 114 101 97 109 115 35 80 117 98 108 105 99 34 93 44 34 111 98 106 101 99 116 34 58 123 34 105 100 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 34 44 34 116 121 112 101 34 58 34 80 101 114 115 111 110 34 44 34 102 111 108 108 111 119 105 110 103 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 47 102 111 108 108 111 119 105 110 103 34 44 34 102 111 108 108 111 119 101 114 115 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 47 102 111 108 108 111 119 101 114 115 34 44 34 105 110 98 111 120 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 47 105 110 98 111 120 34 44 34 111 117 116 98 111 120 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 47 111 117 116 98 111 120 34 44 34 102 101 97 116 117 114 101 100 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 47 99 111 108 108 101 99 116 105 111 110 115 47 102 101 97 116 117 114 101 100 34 44 34 102 101 97 116 117 114 101 100 84 97 103 115 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 47 99 111 108 108 101 99 116 105 111 110 115 47 116 97 103 115 34 44 34 112 114 101 102 101 114 114 101 100 85 115 101 114 110 97 109 101 34 58 34 77 97 114 99 98 101 108 108 105 110 107 120 34 44 34 110 97 109 101 34 58 34 77 97 114 99 32 66 101 108 108 105 110 107 120 34 44 34 115 117 109 109 97 114 121 34 58 34 92 117 48 48 51 99 112 92 117 48 48 51 101 76 101 114 97 97 114 32 97 97 114 100 114 105 106 107 115 107 117 110 100 101 32 111 112 32 122 111 101 107 32 110 97 97 114 32 104 101 116 32 97 110 116 119 111 111 114 100 32 111 112 32 100 101 32 118 114 97 97 103 32 118 97 110 32 57 32 109 105 108 106 97 114 100 46 92 117 48 48 51 99 47 112 92 117 48 48 51 101 34 44 34 117 114 108 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 64 77 97 114 99 98 101 108 108 105 110 107 120 34 44 34 109 97 110 117 97 108 108 121 65 112 112 114 111 118 101 115 70 111 108 108 111 119 101 114 115 34 58 102 97 108 115 101 44 34 100 105 115 99 111 118 101 114 97 98 108 101 34 58 102 97 108 115 101 44 34 112 117 98 108 105 115 104 101 100 34 58 34 50 48 50 50 45 49 49 45 49 56 84 48 48 58 48 48 58 48 48 90 34 44 34 100 101 118 105 99 101 115 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 47 99 111 108 108 101 99 116 105 111 110 115 47 100 101 118 105 99 101 115 34 44 34 112 117 98 108 105 99 75 101 121 34 58 123 34 105 100 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 35 109 97 105 110 45 107 101 121 34 44 34 111 119 110 101 114 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 117 115 101 114 115 47 77 97 114 99 98 101 108 108 105 110 107 120 34 44 34 112 117 98 108 105 99 75 101 121 80 101 109 34 58 34 45 45 45 45 45 66 69 71 73 78 32 80 85 66 76 73 67 32 75 69 89 45 45 45 45 45 92 110 77 73 73 66 73 106 65 78 66 103 107 113 104 107 105 71 57 119 48 66 65 81 69 70 65 65 79 67 65 81 56 65 77 73 73 66 67 103 75 67 65 81 69 65 121 57 47 112 68 90 43 118 103 118 118 67 49 122 68 56 109 107 102 78 92 110 48 77 82 83 97 70 103 83 103 107 108 114 113 54 85 113 90 90 98 88 87 74 48 73 65 115 121 67 117 57 79 81 54 47 73 99 113 119 86 70 83 50 51 105 70 74 120 79 102 77 111 53 115 111 90 78 118 47 53 67 74 90 72 122 92 110 117 116 102 98 82 86 111 116 99 67 66 117 53 111 100 118 48 86 55 108 74 103 88 111 100 55 53 122 107 54 103 66 112 49 43 111 122 54 97 65 111 74 115 104 43 110 57 101 50 76 115 122 70 115 110 120 86 65 72 74 122 48 81 99 92 110 80 69 105 79 105 120 71 122 119 108 43 52 51 47 115 106 75 109 97 72 121 85 73 99 86 85 118 76 70 110 43 81 89 84 119 116 71 73 68 72 105 81 111 111 84 84 69 80 71 74 52 104 82 108 86 49 84 47 119 121 54 56 103 66 92 110 49 50 118 49 112 110 85 57 84 114 79 68 77 112 102 88 104 70 81 122 122 68 78 87 52 118 82 56 120 85 68 109 121 70 53 47 101 117 122 80 80 103 101 53 101 99 104 120 67 113 71 76 50 74 47 106 47 71 68 99 50 111 104 84 92 110 74 77 80 80 115 52 48 114 97 120 71 121 106 97 106 73 116 103 76 66 49 120 72 49 43 103 111 80 76 90 111 70 48 78 106 50 74 89 115 74 43 110 110 116 55 111 43 89 65 65 70 53 103 72 51 87 120 51 108 50 115 112 120 113 92 110 75 119 73 68 65 81 65 66 92 110 45 45 45 45 45 69 78 68 32 80 85 66 76 73 67 32 75 69 89 45 45 45 45 45 92 110 34 125 44 34 116 97 103 34 58 91 93 44 34 97 116 116 97 99 104 109 101 110 116 34 58 91 93 44 34 101 110 100 112 111 105 110 116 115 34 58 123 34 115 104 97 114 101 100 73 110 98 111 120 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 105 110 98 111 120 34 125 44 34 105 99 111 110 34 58 123 34 116 121 112 101 34 58 34 73 109 97 103 101 34 44 34 109 101 100 105 97 84 121 112 101 34 58 34 105 109 97 103 101 47 119 101 98 112 34 44 34 117 114 108 34 58 34 104 116 116 112 115 58 47 47 109 97 115 116 111 100 111 110 45 98 101 108 103 105 117 109 46 98 101 47 115 121 115 116 101 109 47 97 99 99 111 117 110 116 115 47 97 118 97 116 97 114 115 47 49 48 57 47 51 54 54 47 48 54 55 47 52 49 50 47 51 48 52 47 54 55 51 47 111 114 105 103 105 110 97 108 47 101 57 49 57 48 57 52 102 49 98 56 54 49 57 56 100 46 119 101 98 112 34 125 44 34 105 109 97 103 101 34 58 123 34 116 121 112 101 34 58 34 73 109 97 103 101 34 44 34 109 101 100 105 97 84 121 112 101 34 58 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
"""

Worker suddenly stop, after many network errors.

CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
ce998e2fa975 activity-relay_redis_1 89.93% 6.137GiB / 7.789GiB 78.79% 3.86kB / 2.59kB 0B / 0B 4
6a19df2a4d29 activity-relay_worker_1 0.00% 4.816MiB / 7.789GiB 0.06% 2.35kB / 1.25kB 0B / 0B 13
fd959228ee4e activity-relay_server_1 0.00% 4.77MiB / 7.789GiB 0.06% 2.4kB / 1.86kB 0B / 0B 13

Activity-Relay is killing my instance.. I'm running docker, but shortly after booting. it will fill up all of the memory.

nginx proxypass template

Hello friend,

Do you have a template you'd recommend for using this with nginx?

404 when accessing /inbox

I have my relay running through the docker container and I can reach port 8080 with no problem.

however when an instance tries to POST to /inbox or /actor ... I they get a 404 error

systemd after redis

I am not 100% sure but I think start by systemd scripts may fail because redis may not have started (not sure if initial redis connection must be present but I experienced a startup problem). So a solution can be to add After=redis.service to systemd scripts or to mention this as a comment or in documents.

Support Lua custom relaying feature.

Mastodon instances in "secure mode" canot use the relay

Mastodon relays that have AUTHORIZED_FETCH or "secure mode" enabled, do not work with the relay (https://docs.joinmastodon.org/admin/config/#authorized_fetch).

Looks like this is because you have to sign the request when fetching the public key here:

Activity-Relay/models/models.go

Line 100 in 528e801

req, _ := http.NewRequest("GET", url, nil)

Without it, the request returns a 401 from instances that have secure mode enabled.

Why did you fork Machinery?

cd8122b

It just appears that you removed some backends?

Dockerによる起動に失敗する

事象

Dockerによる初回起動時に以下エラーを出力し、起動に失敗します。

go: github.com/RichardKnop/[email protected]: missing go.sum entry; to add it:
	go mod download github.com/RichardKnop/machinery
ERROR: Service 'worker' failed to build: The command '/bin/sh -c mkdir -p /rootfs/usr/bin &&      apk add -U --no-cache git &&      go build -o /rootfs/usr/bin/server -ldflags "-X main.version=$(git describe --tags HEAD)" . &&      go build -o /rootfs/usr/bin/worker -ldflags "-X main.version=$(git describe --tags HEAD)"  ./worker &&      go build -o /rootfs/usr/bin/ar-cli -ldflags "-X main.version=$(git describe --tags HEAD)"  ./cli' returned a non-zero code: 1

推測される原因

Go 1.16以降ではgo.modまたはgo.sumの自動修正が行われないため、依存モジュールの解決に失敗しているものと推測されます。

参考:
https://blog.golang.org/go116-module-changes
※「No automatic changes to go.mod and go.sum」を参照ください。

Segfault when built on Debian 10

Compilation works fine, but binaries segfault when run.

# server 
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xd5791f]

goroutine 1 [running]:
main.initConfig()
	/root/Activity-Relay/main.go:74 +0x50f
main.main()
	/root/Activity-Relay/main.go:97 +0x26

# go version
go version go1.11.6 linux/amd64
# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
# cat ~/Activity-Relay/go.mod 
module github.com/yukimochi/Activity-Relay

go 1.12

require (
	github.com/RichardKnop/machinery v1.6.4
	github.com/Songmu/go-httpdate v1.0.0
	github.com/go-redis/redis v6.15.2+incompatible
	github.com/patrickmn/go-cache v2.1.0+incompatible
	github.com/satori/go.uuid v1.2.0
	github.com/spf13/cobra v0.0.4
	github.com/spf13/viper v1.4.0
	github.com/yukimochi/httpsig v0.1.3
)

replace git.apache.org/thrift.git => github.com/apache/thrift v0.0.0-20181218151757-9b75e4fe745a

Build and run outside Docker

How do I build and run the relay in a production environment, without Docker?

Use latest httpsig.

Custom logger for worker.

machinery の worker ログが、 debug レベルで出力されるため、ログを収集すると容量がかさばってしまう。

Http page error

The relay seems to be working, the logs and the test I ran in my instance seem to support that, however I don't see any page that shows who is in the relay and furthermore where I attempt to connect to the listening port it just returns a plain "404 page not found", it doesn't respect the icon or anything "cosmetic" I set up. Is that even included?

For what I saw in your page I assumed it was going to look like that roughly, is there no http server that shows the instances connected to the relay?

UNIX socket support for REDIS_URL

Hi, I'd like to use a UNIX socket in my REDIS_URL, mainly for an additional security benefit but all variations of using a direct path in the REDIS_URL yaml key do not work.

Sep 06 00:56:53 plus.st relay[847477]: FATA[0000] REDIS_URL: invalid redis URL path: /run/redis/redis.sock

I have tried:

• REDIS_URL: redis:///run/redis/redis.sock
• REDIS_URL: redis:///run/redis/redis.sock:6379
• REDIS_URL: unix:///run/redis/redis.sock
• REDIS_URL: redis://@/run/redis/redis.sock

And none of them work. Is there something wrong I'm doing? If not, can UNIX support be added?

Not relaying third-party traffic

Everything seems to be running, but it’s only relaying activity from my Mastodon server (4.1.0) that is created locally. Activity that has been relayed from third-party relay servers is ignored.

Am I misunderstanding how this is supposed to work? If so, is there a relay server that will relay everything?

[Feature suggestion] Support Delete Actor payload

On Mastodon when a user delete their account, or when a developer execute tootctl self-destruct, the server sends out a Delete Actor activity. Currently it's unsupported by the relay, returning 400.

Change log level?

I have a few servers subscribed to the relay but I'm not sure its working. Is there a way to increase the log level of the worker to see the traffic being relayed?

Support Move types.

Ref. https://fedibird.com/@noellabo/102800095099610244

Define Redis by RedisURL.

ref. https://comm.cx/@ikuradon/101753180559612715

Refactor-1904

多様な ActivityPub Object の取り扱いに耐えられるように、クラスを整理する必要がある。

Questions related to logs output

1. Lots of duplicate users in the Accept relay status? is that normal?

server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/BOMwarnings_bot
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/BOMwarnings_bot
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/shlee
server_1  | Accept Relay Status :  https://mstdn.social/users/SilkyNsa
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/peemee
server_1  | Accept Relay Status :  https://aus.social/users/martintheg
server_1  | Accept Relay Status :  https://aus.social/users/martintheg

2. Lots of failed hosts. How can I remove dead instances easily?

worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_6f8490cb-741b-4777-8ab6-12e102b98176. Error = Post https://social.strueker.net/inbox: dial tcp: lookup social.strueker.net on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_9ee78135-f7fa-455b-a10a-433492a392bf. Error = Post https://lost-angles.im/inbox: dial tcp: lookup lost-angles.im on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_6463e5ad-ae2e-49b5-9306-e97fb83e076d. Error = Post https://social.zwei.net/inbox: dial tcp: lookup social.zwei.net on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_4637ba43-3d49-44a3-ad1f-5142509c061c. Error = Post https://mastodon.zwei.net/inbox: dial tcp: lookup mastodon.zwei.net on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_4b50febf-00aa-4e7e-9f2f-ce71e0137888. Error = Post https://project.social/inbox: dial tcp: lookup project.social on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_036897f8-a1fc-4fb9-aced-29ac23f2d57c. Error = Post https://snel.social/inbox: dial tcp: lookup snel.social on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_90ac8701-15f2-4c02-b28c-40843e55153b. Error = Post https://mastodon.circlelinego.com/inbox: dial tcp: lookup mastodon.circlelinego.com on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_6519968f-76c0-4509-adf7-f3086cf2da1d. Error = Post https://social.joshuacasey.net/inbox: dial tcp: lookup social.joshuacasey.net on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_ee204150-80d4-48a9-a3e4-ed5f492fcda4. Error = Post https://m.zuidbook.com/inbox: dial tcp: lookup m.zuidbook.com on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_fa3f8d5d-0ce7-4e81-95d6-dc4ac1dc2c57. Error = Post https://mypolis.zapto.org/inbox: dial tcp: lookup mypolis.zapto.org on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_14f12ac8-8bee-4d28-98c5-da642e37badd. Error = Post https://lost-angles.im/inbox: dial tcp: lookup lost-angles.im on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_bfe45956-9f16-42c2-8f24-e9afb51c9f6a. Error = Post https://lost-angles.im/inbox: dial tcp: lookup lost-angles.im on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_7cfada8d-4cd1-42b8-82f6-596ff3f823b3. Error = Post https://social.zwei.net/inbox: dial tcp: lookup social.zwei.net on 127.0.0.11:53: no such host
worker_1  | ERROR: 2020/04/11 14:58:07 worker.go:352 Failed processing task task_7eb01510-df3d-440c-a3f8-6e8c3b2ecf65. Error = Post https://project.social/inbox: dial tcp: lookup project.social on 127.0.0.11:53: no such host

Workers failed processing task

Hello

I've just noticed an issue with my relay. The workers aren't processing any tasks, and are just expiring:

ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_09138ca4-7b9c-4263-9f2d-8cd5d4aad69c. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_ba76fe28-f96c-4b45-92d4-0ab095c62975. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_adae57b1-c2d6-43e6-8a93-5d417e8f08bd. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_c5faca59-6f4c-4bbf-99df-dbcc07e42137. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_8817f889-57a0-47fb-8a0e-dadf019af666. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_c2564b76-5994-4a04-a442-2010f42e88d5. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_6de45395-b03d-435d-bacc-fd21342a6704. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_4b60ebe0-9d31-4570-ade0-1640d579df92. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_beba10e9-1c6e-4d90-a222-4dbe1b0fb2ac. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_61e393e4-9ab8-4119-9a0e-d8275e971d8b. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_2a0ab48a-642c-41dd-9581-cc8745f93106. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_ebb48117-06c4-4a1f-be6c-6edf1ab08ccc. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_cc1c2318-15dd-46ed-bde8-f0a8c9f8d3b3. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_0556d110-aaa3-4a6f-8702-68c603150233. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_ce18bf1e-7f45-4257-9ac1-b5273d7b8361. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_d29b7e5d-4ee7-4343-b2d4-c81dad72c722. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_957c5802-555e-4b23-908c-f6de9b163e87. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_7e0c8e0a-5791-424c-9ef6-ca4a1fdf1c24. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_a0ad5aa4-7ecb-4bc9-bf8a-28b2edf61d07. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_b729a0d6-62d7-41fd-ac2b-f2ead0fd6a63. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_a08359e8-c2ae-4a2d-841c-71fd1c897d97. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_c0f385e7-a410-45ae-aa02-0d882ce018b2. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_c164c46b-16af-4321-80c1-c4fe63d247ae. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_82ca904c-7b18-48b7-ad14-8a4e219ec18a. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_83932b37-45a0-4415-9184-f091f6f62549. Error = activity ttl expired
ERROR: 2023/02/28 12:41:38 worker.go:370 Failed processing task task_fd0c196a-29f4-4581-a5c7-d4a3143ba8da. Error = activity ttl expired

There aren't any other errors other than this. I'm not sure where to start debugging?
I'm running v1.2.5 at the moment.

Increase in HTTP 400s

Hello,

I've noticed there has been an increase in HTTP 400 responses lately from my relay.
It appears to be when a user gets deleted on a subscribed instance. Is there any way to perhaps suppress this?

Eg this message from mastodon.social:

POST /inbox HTTP/1.1
Host: relay.intahnet.co.uk
User-Agent: http.rb/5.1.0 (Mastodon/4.0.2; +https://mastodon.social/)
Content-Length: 783
Accept-Encoding: gzip
Content-Type: application/activity+json
Date: Tue, 06 Dec 2022 02:19:11 GMT
Digest: SHA-256=6pIuvMfHG2tkx1M2YyuXFMxs1B29dCsSqRYfwHwUV0Q=
Signature: keyId="https://mastodon.social/users/epochjute52#main-key",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="w5rKlc9E3xaHaMr98+sZi2cFp8jdJc/NMcjHNcKQNF5CkcBNW5/exm08mOTDlIXrEWIrltTUl+tLVTJYJ9mgmdjeJiUJETL4ooGsyyp+wmzaQ3AqV7DxMcweyEdvF6oA907Bboo5df0oN706nmWJeQymakPOty3k+ziIOduJzIxDWq7bC8lK5Z2GpwEz48Rz2vPHGTnkeUd/cKNzw23PVnoeN4tW05gevzranxzuVf0UR5ttYSWndEj3lNqciYIos3jCwUWmg8wnS7r3eUtejP9pbqFrc7KTs/IKhfyF0cmR1Hk/yA6f/pLBZyagMU/mw0/OEuOihTsaZvxOOijLGg=="

{"@context":"https://www.w3.org/ns/activitystreams","id":"https://mastodon.social/users/epochjute52#delete","type":"Delete","actor":"https://mastodon.social/users/epochjute52","to":["https://www.w3.org/ns/activitystreams#Public"],"object":"https://mastodon.social/users/epochjute52","signature":{"type":"RsaSignature2017","creator":"https://mastodon.social/users/epochjute52#main-key","created":"2022-12-06T02:16:43Z","signatureValue":"N7vTgtsxBEBsy7e54OknzubroyYFKxbrAT7gTFuXMeePvPmbEplIOl7cvGlnKl3GeqS/ApNI8CmEMlAHqHaelQugVCY4kPhE5gHmgyVRR0BviXrBkUN22JUiTkwuQkSkXNpkOjyGS7MPHcbG89GOmJofsgHpzAd3zJuL/ie1mHNqN/QkD+AF8vCTb3rUb47HZCwiUQxbhUEf6qLamk3M4Z8/VCt4tbZwJtj0t1Sx0yvjRzAPHqJBj8C7weM5WIwMBx11BBbBGqOz13TE3u61QE4HrDnd2fv2Gw93ENxdl0ihkuysPnN8086XTaFtlzuqSNlQlvw3oykwRlLZTIlt1A=="}}

and the response:

HTTP/1.1 400 Bad Request
Server: nginx/1.21.6
Date: Tue, 06 Dec 2022 02:19:11 GMT
Content-Length: 0
Connection: keep-alive

Federation with Gotosocial: can't follow actor

I'm attempting to subscribe to a activity relay from GotoSocial. Gotosocial managed to fetch the actor account @[email protected], but the follow requests seem to never get approved and are left in a pending state.

The logs from my GTS instance indicate that the follow request cannot be delivered to the Activity Relay's inbox:

gotosocial  | timestamp="23/02/2024 13:21:47.468" func=workers.(*clientAPI).CreateFollowReq level=ERROR requestID=tg723nmd04000b2nb1rg msg="error federating follow request: Follow: error sending activity *typefollow.ActivityStreamsFollow via outbox https://gotosocial.domain/users/gts_user/outbox: func1: error delivering to https://activityrelay.domain/inbox: deliver: POST request to https://activityrelay.domain/inbox failed: status=\"400 Bad Request\" body=\"<empty>\""

I've also opened an issue on GotoSocial's side. See superseriousbusiness/gotosocial/issues/2681. Also the GotoSocial documentation may help as it lists behaviors of GotoSocial that different from other ActivityPub software: https://docs.gotosocial.org/en/latest/federation/federating_with_gotosocial/#quirks

Update

It seems that GotoSocial does not support following relay actor now. Apologies for the intrusion.

YUKIMOCHI Activity-Relay製のサーバーが配信元のサーバーブロック設定を貫通してブロック先に配信し続けている可能性がある

弊 Misskey サーバーでブロック中のサーバーの一部に弊サーバーのポストを受信し続けているものが多数見つかりました。
当方で調査したところ、状況証拠ではございますが上記タイトルの可能性が出てきております。
そちらの状況をご確認いただき、可能なら配信しないようご対応いただければ幸いです。

弊 Misskey サーバーのバックエンド環境

misskey-dev/misskeyでのチケット発行テンプレートより

* Installation Method or Hosting Service: systemd
* Misskey: 2024.7.0
* Node: 20.10.0
* PostgreSQL: 15.2 (Ubuntu 15.2-1.pgdg20.04+1)
* Redis: 7.0.8
* OS and Architecture: Ubuntu 20.04.1 LTS x86_64

ブロック中サーバーへの配信状況

※ リレーＡ：YUKIMOCHI Activity-Relay 製
※ リレーＢ：YUKIMOCHI Activity-Relay 製
※ リレーＣ：楽しもう。Fediverse。
※ 上記3サーバー以外に弊サーバーでのリレー登録なし

リレーＡに登録	リレーＢに登録	リレーＣに登録	件数	現在の状況
－	－	－	9	配信停止中を確認
●	－	－	2	ポスト受信中を確認
－	●	－	1	ポスト受信中を確認
●	●	－	0	（該当なし）
－	－	●	16	配信停止中を確認
●	－	●	0	（該当なし）
－	●	●	3	ポスト受信中を確認
●	●	●	1	ポスト受信中を確認

[Federation] `isActorAbleToBeFollower` stops Friendica instances from following

The current implementation requires the following server actor to have an id ending in /relay:

Activity-Relay/api/resolver.go

Lines 185 to 188 in 7f942e7

	func isActorAbleToBeFollower(actorID *url.URL) bool {
	endingWithRelay := regexp.MustCompile(`/relay$`)
	return endingWithRelay.MatchString(actorID.Path)
	}

However, Friendica allows setting different actor names for the server actor, thus making it impossible for instances with a "wrong" server actor name to connect to Activity-Relay (using LitePub relay style).

I cannot find any documentation or speficication on ActivityPub relays, is it really necessary that actors be named relay?