pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-05-21T12:35:34Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/3053if profile is too big, and you update it, it silently fails2023-05-21T12:35:34ZJeff Cliffif profile is too big, and you update it, it silently fails1) i've been adding more and more text to my profile, once i hit about 5000 characters, if you hit 'save changes' it just silently does nothing
what should happen
either profile should update or some kind of error message should show
wh...1) i've been adding more and more text to my profile, once i hit about 5000 characters, if you hit 'save changes' it just silently does nothing
what should happen
either profile should update or some kind of error message should show
what does happen
silently fails to update the profile
instance: shitposter.club
Backend version 2.4.53-9048-g0f77643d-shitposterclub
Frontend version c807254d
themusicgod1@eva1:~$ wc profile
69 691 4947 profilehttps://git.pleroma.social/pleroma/pleroma/-/issues/3052two factor account names use the email address of the user and not the site i...2023-05-08T00:38:24ZAlexander Lehmanntwo factor account names use the email address of the user and not the site identity<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source):
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): BE 2.4.53-899-g0e1356ef-develop FE b13d8f7e
* Elixir version (`elixir -v` for from source installations, N/A for OTP):
* Operating system:
* PostgreSQL version (`psql -V`):
### Bug description
I have observed this on different public instances.
When turning on 2FA for the account the account description on the code app (I use Authy) uses the email address of the account
and not the userid on the instance like `@username@site.social`. This is a bit confusing when having joined multiple instances with
the same email address. The icon distinguishes the accounts, but the description message is `email@domain.com token is:`
Maybe the best solution would be to mention both like `@user@site.social, account email@domain`https://git.pleroma.social/pleroma/pleroma/-/issues/3051Moderation actions should be run in a transaction2023-05-08T00:38:59ZtusooaModeration actions should be run in a transactionFor example, here
```
def deactivate(%{assigns: %{user: admin}, body_params: %{nicknames: nicknames}} = conn, _) do
users = Enum.map(nicknames, &User.get_cached_by_nickname/1)
{:ok, updated_users} = User.set_activation(users, f...For example, here
```
def deactivate(%{assigns: %{user: admin}, body_params: %{nicknames: nicknames}} = conn, _) do
users = Enum.map(nicknames, &User.get_cached_by_nickname/1)
{:ok, updated_users} = User.set_activation(users, false)
ModerationLog.insert_log(%{
actor: admin,
subject: users,
action: "deactivate"
})
render(conn, "index.json", users: Keyword.values(updated_users))
end
```
The updating and inserting logs should happen in the same transaction, otherwise we might run into cases where the moderation action is done, but not logged.https://git.pleroma.social/pleroma/pleroma/-/issues/3049account lookup leaks information about banned users2023-05-08T00:39:45Ztusooaaccount lookup leaks information about banned usersWe have to acknowledge that the purpose of the lookup includes checking nickname availability (for registration),
so maybe the good thing to do is to return 404 for remote users while return redacted information for local users. Not sure...We have to acknowledge that the purpose of the lookup includes checking nickname availability (for registration),
so maybe the good thing to do is to return 404 for remote users while return redacted information for local users. Not sure how exactly Mastodon-FE uses this endpoint.https://git.pleroma.social/pleroma/pleroma/-/issues/3048Instance Ban2023-05-08T00:37:06ZtusooaInstance BanCurrently there is no such thing in Pleroma as instance ban.
Every user from a banned instance should behave as if they are deactivated individually. MRF Simple only deals with future posts, and everything before the Reject is still in ...Currently there is no such thing in Pleroma as instance ban.
Every user from a banned instance should behave as if they are deactivated individually. MRF Simple only deals with future posts, and everything before the Reject is still in place, available for display, which can be really annoying.https://git.pleroma.social/pleroma/pleroma/-/issues/3047Relayed Creates rejected with "Invalid HTTP Signature"2023-05-08T00:40:01ZthefloweringashRelayed Creates rejected with "Invalid HTTP Signature"<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): from source(?) via nixpkgs
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): 1.13.4
* Operating system: NixOS 22.11
* PostgreSQL version (`psql -V`): 14.6
### Bug description
Relayed Create messages posted to /inbox are rejected with "Invalid HTTP Signature" after 23e91ec8ddb143353b5f685feec33c64370d13c6, which changed the fallback logic for invalid signatures.
The "valid_signature=false" assign has two meanings:
- signature was not valid
- signature key id does not match author (MappedSignatureToIdentityPlug, "payload actor mismatch")
The second meaning applies to relayed Create requests.
Prior to 23e91ec8ddb143353b5f685feec33c64370d13c6, requests with invalid signatures would hit the ActivityPubController inbox handler that (possibly) called `post_inbox_relayed_create`. After the change, they are rejected eagerly with the "Invalid HTTP Signature" error.https://git.pleroma.social/pleroma/pleroma/-/issues/3046[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:pin...2023-05-08T00:40:17Ztusooa[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}
log: `[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}`
code:
```
def websocket_handle(:ping, state), do: {:ok, state}
```
~~Maybe websockex is different from our original implementation?~~ that...
log: `[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}`
code:
```
def websocket_handle(:ping, state), do: {:ok, state}
```
~~Maybe websockex is different from our original implementation?~~ that's unrelevant, websockex is the client implementation, not serverhttps://git.pleroma.social/pleroma/pleroma/-/issues/3044Import following not working as expected on new instance2023-02-19T06:58:01ZVD-15Import following not working as expected on new instance<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): From Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Elixir 1.12.2 (compiled with Erlang/OTP 24)
* Operating system: Ubuntu 22.04 jammy
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 14.5 (Ubuntu 14.5-0ubuntu0.22.04.1)
### Bug description
I recently set up a new instance following the [instructions](https://docs-develop.pleroma.social/backend/installation/debian_based_en/) for my distribution in the Pleroma docs, but I've found myself unable to import my `friends.csv` from my main account.
I follow about 200 people on my main, but when importing the follows via pleroma-FE, the importing process only appeared to follow a single user from the list. I'm aware this process can take a while, so I left it overnight but no progress had been made the following morning. I tried importing the list a few more times, and each time I uploaded the file, it would follow exactly one more user from the list and stop. Eventually it stopped following users altogether and the new account currently sits following 15 people, a handful of which were followed manually.
This is odd to me, because I was able to import almost the exact same follow list on a new Akkoma instance the week prior. That account now follows 134 people. I assume this number is lower than my main because I follow a lot of usernames from dead instances.
I've restarted Pleroma and the server it's running on several times and even re-compiled pleroma and its dependencies just to be sure. I don't think it's a federation issue as I can see posts from the few users I do follow just fine and the import process follows some users from specific instances, but not others on those same instances. Perhaps worth mentioning is that I've configured the instance with an abnormally low upload limit of ~64kB and a character limit of ~1000 characters. I don't know if that would somehow affect the importing process. I can't see any relevant errors in pleroma's logs when running the import process. I did have one error in the logs relating to a user I had followed whose instance had since shut down. While removing that user's handle from `friends.csv` did remove the error, it did not fix the import process.https://git.pleroma.social/pleroma/pleroma/-/issues/3043Re-following bot accounts on non-Pleroma seems to be forbidden2023-05-08T00:35:42ZDohyeon JeonRe-following bot accounts on non-Pleroma seems to be forbidden<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): Not a Pleroma environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Not a Pleroma environment
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Not a Pleroma environment
* Operating system: Not a Pleroma environment
* PostgreSQL version (`psql -V`): Not a Pleroma environment
#### Remote Environment
> NOTE: This bug has arisen between Pleroma and remote (non-Pleroma environment), and I'm at the remote.
* Remote instance 1
* Instance Type: Misskey
* Instance version: [Misskey 13.0.0-beta.30+paring-b25ac66](https://github.com/pikokr/misskey/tree/master)
* Operating system: Alpine Linux v3.17 (Linux kernel 5.15.74-0-lts) on Backend, Data, and Media (Single system hosted)
* Remote instance 2
* Instance Type: Mastodon
* Instance version: [v4.0.2](https://github.com/mastodon/mastodon/releases/tag/v4.0.2)
* Operating System: Could not check
* Bug arisen on (1): [Udongein](https://udongein.xyz)
* Pleroma version: Backend 2.5.0; Frontend 3a507ba9b
* Installation type: Could not check
* Elixir version: Could not check
* Operating system: Could not check
* PostgreSQL version: Could not check
* Bug arisen on (2): [blobcat](https://blob.cat)
* Pleroma version: Backend 2.2.50-745-g0ad6ea20-develop; Frontend 39f85871
* Installation type: Could not check
* Elixir version: Could not check
* Operating system: Could not check
* PostgreSQL version: Could not check
### Bug description
When you followed a bot user and unfollowed, you can never re-follow again but it just says "Follow request pending".
#### Reproduce steps
1. Follow a bot user of Pleroma on non-Pleroma remote.
2. Unfollow them.
3. Try follow them again.https://git.pleroma.social/pleroma/pleroma/-/issues/3042Periodic job for pruning old content2023-09-17T21:42:51ZpiggoPeriodic job for pruning old contentI fixed my issues with incredibly slow timelines and query timeouts by deleting disabled users, old activities and objects (older than Jan 1 2021), then vacuum full. How about this were a built-in job that runs every X days or something,...I fixed my issues with incredibly slow timelines and query timeouts by deleting disabled users, old activities and objects (older than Jan 1 2021), then vacuum full. How about this were a built-in job that runs every X days or something, configurable of course?
It could also be limited to remote only and posts the local users never interacted with, but that makes the query more complicated.
Deleting old stuff also solves the issue of ever growing storage requirements. This almost halved my postgres folder in size.
In my case this deleted about 3 millions of activities and couple hundred thousand objects
This change was needed to delete objects - the constraint prevented anything being deleted:
```
ALTER TABLE deliveries DROP CONSTRAINT "deliveries_object_id_fkey", ADD CONSTRAINT "deliveries_object_id_fkey" FOREIGN KEY (object_id) REFERENCES objects(id) ON DELETE CASCADE;
```
Deleting users needed a new index, but I forgot what it was - it shows up when running explain (timing) when deleting a single user.https://git.pleroma.social/pleroma/pleroma/-/issues/3041Inconsistent inclusion of port in HTTP signatures2023-05-08T00:41:29ZGeoff TaylorInconsistent inclusion of port in HTTP signaturesI'm using a small, non-public installation of the docker container git.pleroma.social:5050/pleroma/pleroma:latest with backend version 2.4.53-863-g9f708037
(I'm not a real Pleroma user, I'm just using it to send some ActivityPub stuff t...I'm using a small, non-public installation of the docker container git.pleroma.social:5050/pleroma/pleroma:latest with backend version 2.4.53-863-g9f708037
(I'm not a real Pleroma user, I'm just using it to send some ActivityPub stuff to code I'm running.)
I've noticed that when Pleroma requests, for example, an Actor's data, it uses a `GET` request with the key `/internal/fetch#main-key`. When it signs the request, it uses the Host header *without* the port.
When it's sending data from a user, it uses a `POST` request with the person's key `/users/personname#main-key`. When it signs the request, it uses the Host header *with* the port.
In other words:
* When it gets http://localhost:8080/users/personname it generates the signature with `host: localhost`.
* When it sends to http://localhost:8080/users/personname/outbox it generates the signature with `host: localhost:8080`
The RFC for HTTP signatures doesn't seem to mention one way or the other whether to use the port so I don't know which one is 'right'. It does seem they should be consistent though.
This inconsistency only appears if the target (my code) is running on a non-default port, which means this likely applies to very few people (mainly developers?) so has very little impact.
I've got a workaround for it in my code so it's not a big deal. I just figured I should mention it here now that I've noticed it.https://git.pleroma.social/pleroma/pleroma/-/issues/3039MRF SimplePolicy: `check_ftl_removal` only supports tuples as configuration, ...2023-05-08T00:36:22ZpiggoMRF SimplePolicy: `check_ftl_removal` only supports tuples as configuration, no single string (legacy)```
pleroma | 10:32:21.655 [info] POST /api/v1/statuses
pleroma |
pleroma | 10:32:21.660 request_id=FzXaMT1xvIFX2yUAAD8h [error] Internal server error: %FunctionClauseError{args: nil, arity: 1, clauses: nil, functio...```
pleroma | 10:32:21.655 [info] POST /api/v1/statuses
pleroma |
pleroma | 10:32:21.660 request_id=FzXaMT1xvIFX2yUAAD8h [error] Internal server error: %FunctionClauseError{args: nil, arity: 1, clauses: nil, function: :"-instance_list_from_tuples/1-fun-0-", kind: nil, module: Pleroma.Web.ActivityPub.MRF}
pleroma |
pleroma | 10:32:21.661 request_id=FzXaMT1xvIFX2yUAAD8h [info] Sent 500 in 5ms
pleroma |
pleroma | 10:32:21.661 [error] #PID<0.4543.0> running Pleroma.Web.Endpoint (connection #PID<0.4135.0>, stream id 20) terminated
pleroma | Server: piggo.space:80 (http)
pleroma | Request: POST /api/v1/statuses
pleroma | ** (exit) an exception was raised:
pleroma | ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
pleroma | (pleroma 2.5.0) anonymous fn("botsin.space") in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
pleroma | (elixir 1.12.2) lib/enum.ex:1582: Enum."-map/2-lists^map/1-0-"/2
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:89: Pleroma.Web.ActivityPub.MRF.SimplePolicy.check_ftl_removal/2
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:217: Pleroma.Web.ActivityPub.MRF.SimplePolicy.filter/1
pleroma | (elixir 1.12.2) lib/enum.ex:2385: Enum."-reduce/3-lists^foldl/2-0-"/3
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/activity_pub.ex:130: Pleroma.Web.ActivityPub.ActivityPub.insert/4
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/activity_pub.ex:299: Pleroma.Web.ActivityPub.ActivityPub.do_create/2
pleroma | (ecto_sql 3.9.0) lib/ecto/adapters/sql.ex:1190: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
pleroma |
pleroma | 10:32:21.697 [info] GET /api/v1/timelines/home
```https://git.pleroma.social/pleroma/pleroma/-/issues/3037Install v2.5.0 on debian 11 (bullseye) via source fails. Missing Elixir v1.112024-01-06T02:50:03ZMatthias StefanInstall v2.5.0 on debian 11 (bullseye) via source fails. Missing Elixir v1.11<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): From Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): v2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): v1.10.3
* Operating system: Debian Bullseye 11
* PostgreSQL version (`psql -V`): 13.9
### Bug description
In the install documentation for pleroma there is a variant described for installing it on debian 11: [Pleroma Install Guide](https://docs-develop.pleroma.social/backend/installation/debian_based_en/)
> This guide will assume you are on Debian 11 (“bullseye”) or later.
This is no longer valid, since Debian 11 supports only v1.10.3 of Elixir: [Debian Package Elixir](https://packages.debian.org/bullseye/elixir)
When you try to compile pleroma, the following appears:
```
sudo -Hu pleroma MIX_ENV=prod mix compile
** (Mix) You're trying to run :pleroma on Elixir v1.10.3 but it has declared in its mix.exs file it supports only Elixir ~> 1.11
```https://git.pleroma.social/pleroma/pleroma/-/issues/3036Suggestion: add email_whitelist option to Pleroma.User config2023-05-08T00:42:01Zl mSuggestion: add email_whitelist option to Pleroma.User config- only allow users with allowed email domains to register
- has no effect when empty list, which is the default option
- if given domain is in both email_blacklist and email_whitelist, blacklist has priority- only allow users with allowed email domains to register
- has no effect when empty list, which is the default option
- if given domain is in both email_blacklist and email_whitelist, blacklist has priorityhttps://git.pleroma.social/pleroma/pleroma/-/issues/3034Emails not being sent2023-05-08T00:41:12ZWyatt ParkerEmails not being sentSo I have Pleroma with Soapbox and I'm trying to figure out how come no emails are being sent. I've check/tested 465/587 with telnet and can telnet just fine to my google workspace.
I've even tested with SendMail API/AmazonSES both API a...So I have Pleroma with Soapbox and I'm trying to figure out how come no emails are being sent. I've check/tested 465/587 with telnet and can telnet just fine to my google workspace.
I've even tested with SendMail API/AmazonSES both API and SMTP credentials on these ports through Pleroma and no emails, but again, Telnet is successful.
Port 25 is not an option as DigitalOcean is blocking it. I've tried to reach out to Pleroma through their IRC and no response for 2 days. Was hoping someone could shed some light on how come registration emails are not going through.
Thanks in advance.https://git.pleroma.social/pleroma/pleroma/-/issues/3032Non-breaking migration process2023-05-08T00:43:30ZtusooaNon-breaking migration processWe should set up a non-breaking migration process.
This means we should strive to minimize the downtime for the migrations.
Preferably, the process should behave as follows:
0. Run the migrations that will not break old code
1. Swap o...We should set up a non-breaking migration process.
This means we should strive to minimize the downtime for the migrations.
Preferably, the process should behave as follows:
0. Run the migrations that will not break old code
1. Swap old code with new code
2. Run migrations that will not break current code, while new code is runninghttps://git.pleroma.social/pleroma/pleroma/-/issues/3028search only finds users who start with the search term2023-05-08T00:45:35Zrobinsearch only finds users who start with the search termWhen you search for a user, it only finds results that start with your search term; it would be much more useful (at least to me) if it found results that contain the term.
The specific example that inspired me to open an issue was sear...When you search for a user, it only finds results that start with your search term; it would be much more useful (at least to me) if it found results that contain the term.
The specific example that inspired me to open an issue was searching for an account I'd just added to the instance I use to mirror Twitter accounts so they can be followed from the fediverse (https://twitter.oksocial.net); the account is "PlayARKMobile", but all I could remember was that it was related to Ark.
Searching for "ark" on that instance finds no users, but searching for "play" does find it.
(I had to look back at the the mirror config for the username. :-)https://git.pleroma.social/pleroma/pleroma/-/issues/3026Think about how to handle excessive deletes for the same object2023-05-08T00:35:10ZlainThink about how to handle excessive deletes for the same objectI've come across two misskey objects that I have over 2000 deletes for in my db. This isn't actively hurting anything, but it seems like a bug, although there could be legitimate reasons for sending multiple deletes for the same object. ...I've come across two misskey objects that I have over 2000 deletes for in my db. This isn't actively hurting anything, but it seems like a bug, although there could be legitimate reasons for sending multiple deletes for the same object. Maybe ignoring a delete if we have already deleted the object would be good.tusooatusooahttps://git.pleroma.social/pleroma/pleroma/-/issues/3025Not getting all emoji when downloading pack from remote instance2023-05-08T00:46:46ZHJNot getting all emoji when downloading pack from remote instanceImporting remote emoji pack seem to download first 30 of the pack and fails the rest, emoji are still created but have no files for them.Importing remote emoji pack seem to download first 30 of the pack and fails the rest, emoji are still created but have no files for them.https://git.pleroma.social/pleroma/pleroma/-/issues/3019Force unfollow a relay?2023-05-08T00:51:18ZWalter CoolForce unfollow a relay?Hi,
I been with two damn relays who been stuck for a year and there is no way to get rid of them.
No matter if using Admin FE or CLI to unfollow, they are not removed.
Any good way to workaround this issue? I have no idea where are re...Hi,
I been with two damn relays who been stuck for a year and there is no way to get rid of them.
No matter if using Admin FE or CLI to unfollow, they are not removed.
Any good way to workaround this issue? I have no idea where are relays stored at database.
Thanks!