pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2022-09-27T21:50:47Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/2940Failing test: DELETE /api/pleroma/admin/instance_document/:name deletes the i...2022-09-27T21:50:47ZHélènepleroma-dev@helene.moeFailing test: DELETE /api/pleroma/admin/instance_document/:name deletes the instance documentUnit tests fails with:
```
1) test DELETE /api/pleroma/admin/instance_document/:name deletes the instance document (Pleroma.Web.AdminAPI.InstanceDocumentControllerTest)
test/pleroma/web/admin_api/controllers/instance_document_cont...Unit tests fails with:
```
1) test DELETE /api/pleroma/admin/instance_document/:name deletes the instance document (Pleroma.Web.AdminAPI.InstanceDocumentControllerTest)
test/pleroma/web/admin_api/controllers/instance_document_controller_test.exs:83
Assertion with == failed
code: assert html_response(conn_resp, 200) == "Custom instance panel"
left: "<div style=\"margin-left:12px; margin-right:12px\">\n<p>Welcome to <a href=\"https://pleroma.social\" target=\"_blank\">Pleroma!</a></p>\n<p><a href=\"/main/all\">Pleroma FE</a></p>\n</div>\n\n"
right: "Custom instance panel"
stacktrace:
test/pleroma/web/admin_api/controllers/instance_document_controller_test.exs:91: (test)
```
Job [#219849](https://git.pleroma.social/pleroma/pleroma/-/jobs/219849) for 7f63b4c315653b4ed35afa326fc194feec21aea3https://git.pleroma.social/pleroma/pleroma/-/issues/2935Domain change breaks federation2022-09-07T11:50:51ZAmber WalkerDomain change breaks federation<!--
### 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): OTP
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.4.3
* Elixir version (`elixir -v` for from source installations, N/A for OTP): N/A
* Operating system: Debian
* PostgreSQL version (`psql -V`): 13.7
### Bug description
After changing the domain name of a pleroma instance, relaying is broken.
Doing
```
./bin/pleroma_ctl relay follow https://snowdin.town/relay
./bin/pleroma_crl relay list
```
doesn't seem to add the relay. The list is empty. When trying to access the relay settings in the pleroma-fe, I get `Request failed with status code 400 - [object Object]`
The instance used to be on [`https://pleroma.astralchan.xyz`](https://pleroma.astralchan.xyz) but has been moved to [`https://pl.astralchan.xyz`](https://pl.astralchan.xyz). This was done via editing `/etc/pleroma/config.exs` and `/etc/nginx/sites-enabled/pleroma`, then
```
./bin/pleroma_ctl update
./bin/pleroma_ctl migrate
systemctl restart pleroma
```
I notice the [relay on my instance](https://pl.astralchan.xyz/relay) just says "Not found"
Is there any way to fix and keep followers / etc ?
It would be nice if there was docs on how to transfer over to new domain.https://git.pleroma.social/pleroma/pleroma/-/issues/2931BBS: Add translation support2023-04-26T12:19:48ZHaelwennBBS: Add translation supporthttps://git.pleroma.social/pleroma/pleroma/-/issues/2930get_or_fetch won't fetch by nickname if nickname starts with "http"2022-10-30T00:38:23ZIljaget_or_fetch won't fetch by nickname if nickname starts with "http"Something @helene discovered, but I didn't see an issue or MR yet.
See https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L2119-2122
```elixir
@doc "Gets or fetch a user by uri or nickname."
@spec get_or_...Something @helene discovered, but I didn't see an issue or MR yet.
See https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L2119-2122
```elixir
@doc "Gets or fetch a user by uri or nickname."
@spec get_or_fetch(String.t()) :: {:ok, User.t()} | {:error, String.t()}
def get_or_fetch("http" <> _host = uri), do: get_or_fetch_by_ap_id(uri)
def get_or_fetch(nickname), do: get_or_fetch_by_nickname(nickname)
```
I don't think we allow `:` and `/` in nicknames, so these should probably be part of the check (e.g. check if it starts with either `http://` or `https://`).https://git.pleroma.social/pleroma/pleroma/-/issues/2919Group chats2022-08-19T01:27:23ZLamar NutsGroup chats**Group chats** should only be in local instance and not federated as soon it's implemented.**Group chats** should only be in local instance and not federated as soon it's implemented.https://git.pleroma.social/pleroma/pleroma/-/issues/2916新用户注册无法收到验证邮件,而且后台没有任何报错 (new users can't receive verification mails upon reg...2022-08-09T23:10:25Zyu chiu新用户注册无法收到验证邮件,而且后台没有任何报错 (new users can't receive verification mails upon registration, and no error logs in the background)Pleroma 2.4.3
postfix mail_version = 3.5.13
When I turn on "Account activation required" , new users don't receive emails.
![image](/uploads/7159bc76ae5effab55b44433b3e25948/image.png)
Use `su pleroma -s $SHELL -lc "./bin/pleroma_ctl em...Pleroma 2.4.3
postfix mail_version = 3.5.13
When I turn on "Account activation required" , new users don't receive emails.
![image](/uploads/7159bc76ae5effab55b44433b3e25948/image.png)
Use `su pleroma -s $SHELL -lc "./bin/pleroma_ctl email test --to xxx@foxmail.com"` to send and receive emails normally.
"Sender Email Address" has also been filled in correctly
"Mailer" has been started normally.
![image](/uploads/9882099553f191b54b767086aa9b888c/image.png)
"var/log/mail.log" does not have any log output
I don't know if my configuration is wrong? Or is there a problem with the mail system?https://git.pleroma.social/pleroma/pleroma/-/issues/2912Activities rejected by MRF being retried by oban worker due to match errors i...2022-08-12T01:37:41ZiamtakingiteasyActivities rejected by MRF being retried by oban worker due to match errors in transmogrifierIncoming federated activites when being processed by transmogrifier are having a chance to be rejected by one of local MRFs.
Transmogrifier calls to common_pipeline (e.g. https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/ple...Incoming federated activites when being processed by transmogrifier are having a chance to be rejected by one of local MRFs.
Transmogrifier calls to common_pipeline (e.g. https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/transmogrifier.ex#L495-516 ) however do not account for possibility of rejection, resulting in error being returned from oban job invocation and causing it to be retried at later time until retry limit is exceeded.
Possible solution may be to explicitly handle `:reject`s in transmogrifier calls to `common_pipeline`, or pass it up the call chain, ultimately handling reject as an `:ok` result, to avoid further job retries.
<details>
<summary>Incorrect assumptions, has nothing to do with actual problem, see https://git.pleroma.social/pleroma/pleroma/-/issues/2912#note_92995</summary>
Generally, when `:reject` is returned from MRF, it is interpreted by remote instance as an error, and activity re-delivery attempts are being made, receiving `:reject` again and repeating the cycle until remote instance exhausts delivery retry count for this activity.
This may put some excessive and most importantly pointless strain on the network as a whole, clogging outgoing queues and requiring receiving instance to react to the same activity again and again. Probably best solution would be to equate `:reject` with a distinct error and make sure every project would handle it accordingly, but it may be difficult or even unrealistic to get every project on board. At the same time, it is possible to return fake OK status, while executing no side-effects locally. This may have it's own issues, hence why I'd like to discuss this and consider possible pros and cons first.
As far as implementation goes, simply adding a new symbol handling to the `do_common_pipeline`, e.g.
```diff
def do_common_pipeline(message, meta) do
with {_, {:ok, message, meta}} <- {:validate, object_validator().validate(message, meta)},
{_, {:ok, message, meta}} <- {:mrf, mrf().pipeline_filter(message, meta)},
{_, {:ok, message, meta}} <- {:persist, activity_pub().persist(message, meta)},
{_, {:ok, message, meta}} <- {:side_effects, side_effects().handle(message, meta)},
{_, {:ok, _}} <- {:federation, maybe_federate(message, meta)} do
{:ok, message, meta}
else
{:mrf, {:reject, message, _}} -> {:reject, message}
+ {:mrf, {:ignore, message, meta}} -> {:ok, message, meta}
e -> {:error, e}
end
end
```
with this `:ignore` returned from MRF instead of `:reject` seem to be sufficient to the requirement of ending the activity processing on both ends.
There is a tangentially related issue #2765 for the case when local instance is the initiator of a fetch action and this action being retried even after got rejected by local MRF policy.
This issue is more specific to the case when initiator is the remote instance, not necessarily pleroma, trying to re-deliver an activity previously rejected by a local MRF policy, with local record of rejected activities doing nothing to prevent unnecessary network interaction.
</details>https://git.pleroma.social/pleroma/pleroma/-/issues/2908Questionable implementation of show_reactions?2022-08-03T02:33:42ZSean KingQuestionable implementation of show_reactions?I don't know if it's because I'm on FSE, or whatever. But I noticed that I can still see that a user from Spinster liked a post of someone from Gleasonator despite those instances seemingly having being able to see who liked or reacted t...I don't know if it's because I'm on FSE, or whatever. But I noticed that I can still see that a user from Spinster liked a post of someone from Gleasonator despite those instances seemingly having being able to see who liked or reacted to something disabled.
For example, viewing a Gleasonator post over FSE shows that another user from Gleasonator has liked this post:
![image](/uploads/42fb8f4813fa002d8519a1aeccf6ff11/image.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2902block actions do not delete follow activities and cause out-of-sync relations...2022-08-12T01:32:21ZSadposterblock actions do not delete follow activities and cause out-of-sync relationshipshey look at me being nice to you, this is such a longstanding bug that i'd feel bad not letting you know how to replicate it
[User.get_follow_state/3](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L1076) ...hey look at me being nice to you, this is such a longstanding bug that i'd feel bad not letting you know how to replicate it
[User.get_follow_state/3](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L1076) uses a fallback of [Utils.fetch_latest_follow/2](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/utils.ex#L489) to fill the `following` field on relationships
however, a [User.block/2](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L1567) call, which in turn called [User.unfollow/2](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L1059), does not remove any follow activities from the database
this means that whilst we've removed the `FollowingRelationship` entry and `FollowingRelationship.get/2` returns `nil`, the value picked up by `User.get_follow_state/3` will fall back to the last follow, which was an accept. thus, the two functions will arrive at different results when asked "is "user_a" following "user_b"?
this can result in the very amusing relationship of `following: true, blocking: true` being rendered.
to get into follow hell:
1. have 2 instances
2. follow remote_user with local_user
3. ensure the accept returns, accept if neccesary
4. block remote_user
5. observe that you're both blocking _and_ following the userhttps://git.pleroma.social/pleroma/pleroma/-/issues/2901Can't remote follow Owncast instance2022-12-18T19:49:16ZlewdthewidesCan't remote follow Owncast 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): Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.4.52-554-g3193f18c-develop
* Elixir version (`elixir -v` for from source installations, N/A for OTP): 1.13.2 (compiled with Erlang/OTP 24)
* Operating system: Arch Linux
* PostgreSQL version (`psql -V`): 14.3
### Bug description
I am unable to remote follow my Owncast instance at https://live.uknow.moe. After clicking the Follow button on the Owncast instance & inputting the instance username@server, I receive a HTTP 500 error
```
Jul 19 14:43:55 Wides-PL pleroma[1169]: request_id=FwNPQqk0iKdsrnoAAcLx [error] Internal server error: %FunctionClauseError{args: nil, arity: 1, clauses: nil, function: :"-object_to_user_data/1-fun-1-", kind: nil, module: Pleroma.Web.ActivityPub.ActivityPub}
Jul 19 14:43:55 Wides-PL pleroma[1169]: [error] #PID<0.4298.1> running Pleroma.Web.Endpoint (connection #PID<0.4297.1>, stream id 1) terminated
Server: hidamari.apartments:80 (http)
Request: GET /ostatus_subscribe?acct=https://stream.uknow.moe/federation/user/widestream
** (exit) an exception was raised:
** (Protocol.UndefinedError) protocol Phoenix.HTML.Safe not implemented for %{errors: %{detail: "Internal server error"}} of type Map. This protocol is implemented for the following type(s): Atom, BitString, Date, DateTime, Decimal, Float, Integer, List, NaiveDateTime, Phoenix.HTML.Form, Phoenix.LiveComponent.CID, Phoenix.LiveView.Component, Phoenix.LiveView.Comprehension, Phoenix.LiveView.JS, Phoenix.LiveView.Rendered, Time, Tuple
(phoenix_html 3.1.0) lib/phoenix_html/safe.ex:1: Phoenix.HTML.Safe.impl_for!/1
(phoenix_html 3.1.0) lib/phoenix_html/safe.ex:15: Phoenix.HTML.Safe.to_iodata/1
(phoenix 1.5.9) lib/phoenix/controller.ex:776: Phoenix.Controller.render_and_send/4
(phoenix 1.5.9) lib/phoenix/endpoint/render_errors.ex:78: Phoenix.Endpoint.RenderErrors.instrument_render_and_send/5
(phoenix 1.5.9) lib/phoenix/endpoint/render_errors.ex:64: Phoenix.Endpoint.RenderErrors.__catch__/5
(phoenix 1.5.9) lib/phoenix/endpoint/cowboy2_handler.ex:65: Phoenix.Endpoint.Cowboy2Handler.init/4
(cowboy 2.9.0) /opt/pleroma/deps/cowboy/src/cowboy_handler.erl:37: :cowboy_handler.execute/2
(cowboy 2.9.0) /opt/pleroma/deps/cowboy/src/cowboy_stream_h.erl:306: :cowboy_stream_h.execute/3
```
I can also reproduce this with my shitposter.club account. Mastodon instances seem to handle the remote follow fine, or at the very least don't 500
I didn't treat this as an Owncast issue because I saw that they ran their own federation tests earlier this year:
https://github.com/owncast/owncast/issues/1211#issuecomment-1012584506
edit> the Owncast instance is now hosted at https://live.uknow.moe. It's shorter :)https://git.pleroma.social/pleroma/pleroma/-/issues/2900Exploring alternative resolutions for the notice compatibility routes2022-12-24T04:55:15ZSean KingExploring alternative resolutions for the notice compatibility routesAs some may know, we have had a strong controversy over a particular MR that added "notice compatibility routes". For this reason, we should discuss and act on an alternative solution before version 2.5.0 releases. Here's some ideas:
- ...As some may know, we have had a strong controversy over a particular MR that added "notice compatibility routes". For this reason, we should discuss and act on an alternative solution before version 2.5.0 releases. Here's some ideas:
- We can make the routes optional using a Pleroma configuration setting. I made an implementation in !3579. However, this does come with a downside, which is that instance admins would have to restart the server if they changed that setting.
- We can remove the implementation and document ways to achieve the same thing with reverse proxies. I believe @debula might know how to do this for Pleroma instances that have Soapbox as their primary frontend.
If there is any better ideas for resolving this, we are open to them.
**BEFORE RESPONDING, PLEASE READ THE FOLLOWING:**
Even though these are in early stages, we expect everyone that intends to be involved in this discussion to abide by our [guidelines on acceptable behavior](https://git.pleroma.social/pleroma/pleroma-meta/-/merge_requests/2).2.5.0https://git.pleroma.social/pleroma/pleroma/-/issues/2894blacklisted_emails should be case-insensitive2022-07-11T04:04:38ZSean Kingblacklisted_emails should be case-insensitiveWhile working on and testing case-sensitivity issues with #2888, I happened notice a similar issue when I did a test for `blacklisted_domains`:
![image](/uploads/3bf0d5c1c90f4d8f4f5dc16f55a5a804/image.png)
![image](/uploads/acfa1452c71...While working on and testing case-sensitivity issues with #2888, I happened notice a similar issue when I did a test for `blacklisted_domains`:
![image](/uploads/3bf0d5c1c90f4d8f4f5dc16f55a5a804/image.png)
![image](/uploads/acfa1452c71ff7eae40a515b6f7d2e2c/image.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2889Docker image: Error relocating beam.smp: pthread_getname_np: symbol not found2023-10-04T21:04:41ZtusooaDocker image: Error relocating beam.smp: pthread_getname_np: symbol not foundIt seems that it is because the alpine version we use in the release image is older than the version it is built on.
https://github.com/erlef/docker-elixir/issues/41It seems that it is because the alpine version we use in the release image is older than the version it is built on.
https://github.com/erlef/docker-elixir/issues/41https://git.pleroma.social/pleroma/pleroma/-/issues/2887Give admins a choice to not strip reported statuses when closing a report2022-11-12T17:55:52ZtusooaGive admins a choice to not strip reported statuses when closing a reportCurrently, when a report is closed, the reported statuses are reduced to ids. This is not good for recording purposes.
I once got asked by a user why a specific user was banned. I turned to the moderation log, and could not find the rec...Currently, when a report is closed, the reported statuses are reduced to ids. This is not good for recording purposes.
I once got asked by a user why a specific user was banned. I turned to the moderation log, and could not find the recorded status in the report, as the report has been closed.https://git.pleroma.social/pleroma/pleroma/-/issues/2885furnitures2022-06-13T15:38:38Zbiny josefurnituresReady to start shopping for the perfect bedroom furniture? Get some inspiration from our 5 reasons why you need Rangkul Island bedroom furniture.Are you a fan of the Asian lifestyle and home décor, but not feeling up to spending a lot of...Ready to start shopping for the perfect bedroom furniture? Get some inspiration from our 5 reasons why you need Rangkul Island bedroom furniture.Are you a fan of the Asian lifestyle and home décor, but not feeling up to spending a lot of money on high-tech pieces? Stop dreaming and start living in style today with one of our beautifully designed rattan furniture sets. If you’re looking for a reliable rental company in Bali, there’s only one choice: J&B Rentals. I’ve been renting furniture for almost three years, and I have the best [bali rattan furniture ](https://bungalowlivingdubai.com/furniture) experiences with this company. All my furniture comes from them – everything from beds, tables and chairs to lamps and other household stuff. The best thing about J&B Rentals is that you can rent anything you want for a week for a very affordable price.If you are looking to buy furniture in Bali, Indonesia, do you know where to find the best bargains? I am going to show you a comprehensive guide to buying furniture in Bali, Indonesia.https://git.pleroma.social/pleroma/pleroma/-/issues/2884Incoming federation should not return 5xx error code2023-12-22T11:04:26ZtusooaIncoming federation should not return 5xx error code```
def inbox(%{assigns: %{valid_signature: true}} = conn, %{"nickname" => nickname} = params) do
with %User{} = recipient <- User.get_cached_by_nickname(nickname),
{:ok, %User{} = actor} <- User.get_or_fetch_by_ap_id(para...```
def inbox(%{assigns: %{valid_signature: true}} = conn, %{"nickname" => nickname} = params) do
with %User{} = recipient <- User.get_cached_by_nickname(nickname),
{:ok, %User{} = actor} <- User.get_or_fetch_by_ap_id(params["actor"]),
true <- Utils.recipient_in_message(recipient, actor, params),
params <- Utils.maybe_splice_recipient(recipient.ap_id, params) do
Federator.incoming_ap_doc(params)
json(conn, "ok")
end
end
```
Currently if there is no match it will return 500. It should really return 4xx error codes.
Not sure if the error code is related, but I keep receiving POST requests for a *deleted* account's inbox from another Pleroma instance.https://git.pleroma.social/pleroma/pleroma/-/issues/2871"local public" is neither local nor public2022-08-02T05:39:51Ztusooa"local public" is neither local nor publichttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/2289 adds a functionality to post to "local public" (`{instance}/#Public`). However, there are several problems:
- Not searchable
- ~~Cannot be seen by non-followers~~ Does not...https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2289 adds a functionality to post to "local public" (`{instance}/#Public`). However, there are several problems:
- Not searchable
- ~~Cannot be seen by non-followers~~ Does not show up in user profile <- need to change thread_visibility function in db?
- Cannot be seen on public timeline even for registered users
- Still federated to other servers (the cc followers attribute)
Sample activity:
```
%Pleroma.Activity{
__meta__: #Ecto.Schema.Metadata<:loaded, "activities">,
actor: "https://kazv.moe/users/tusooa",
bookmark: #Ecto.Association.NotLoaded<association :bookmark is not loaded>,
data: %{
"actor" => "https://kazv.moe/users/tusooa",
"cc" => ["https://kazv.moe/users/tusooa/followers"],
"context" => "https://kazv.moe/contexts/945a4d79-8200-48e1-858e-14f5404fb71a",
"context_id" => 3472496,
"directMessage" => false,
"id" => "https://kazv.moe/activities/9bef8bde-efc2-45e2-97e3-4731d5c57c9b",
"object" => "https://kazv.moe/objects/f7b7d66e-0161-4634-9926-d4e53f3f79b8",
"published" => "2022-05-04T22:24:43.865694Z",
"to" => ["https://kazv.moe/#Public"],
"type" => "Create"
},
id: "AJ7e4imq6XYHnk9API",
inserted_at: ~N[2022-05-04 22:24:43],
local: true,
notifications: #Ecto.Association.NotLoaded<association :notifications is not loaded>,
object: #Ecto.Association.NotLoaded<association :object is not loaded>,
pagination_id: nil,
recipients: ["https://kazv.moe/#Public",
"https://kazv.moe/users/tusooa/followers", "https://kazv.moe/users/tusooa"],
report_notes: #Ecto.Association.NotLoaded<association :report_notes is not loaded>,
thread_muted?: nil,
updated_at: ~N[2022-05-04 22:24:43],
user_actor: #Ecto.Association.NotLoaded<association :user_actor is not loaded>
}
```https://git.pleroma.social/pleroma/pleroma/-/issues/2870Unable to search posts by CW title2022-07-06T21:16:20ZdebulaUnable to search posts by CW titleFull text search is great in Pleroma. But [the default index `object_fts`](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/mix/tasks/pleroma/database.ex#L224) only indexes the inner text (`content`) without CW title (`summa...Full text search is great in Pleroma. But [the default index `object_fts`](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/mix/tasks/pleroma/database.ex#L224) only indexes the inner text (`content`) without CW title (`summary`).
This may be inconvenient at times. Can you help improve it? Thanks in advance.https://git.pleroma.social/pleroma/pleroma/-/issues/2869MastoFE usage from Pleroma doesn't work as-described2022-05-06T11:45:38ZNEETzscheMastoFE usage from Pleroma doesn't work as-describedIn the [Documentation](https://docs.pleroma.social/backend/) it says:
>Mastodon interface
>
>If the Pleroma interface isn't your thing, or you're just trying something new but you want to keep using the familiar Mastodon interface, we g...In the [Documentation](https://docs.pleroma.social/backend/) it says:
>Mastodon interface
>
>If the Pleroma interface isn't your thing, or you're just trying something new but you want to keep using the familiar Mastodon interface, we got that too! Just add a "/web" after your instance url (e.g. https://pleroma.soykaf.com/web) and you'll end on the Mastodon web interface, but with a Pleroma backend! MAGIC! The Mastodon interface is from the Glitch-soc fork. For more information on the Mastodon interface you can check the Mastodon and Glitch-soc documentation.
>
>Remember, what you see is only the frontend part of Mastodon, the backend is still Pleroma.
But try actually going to `/web` on any of these locations:
* https://kiwifarms.cc/web
* https://shitposter.club/web
* https://pl.iddqd.social/web
None of them work. When did this break, and if the issue is the way to get onto MastodonFE has changed, how has it changed?https://git.pleroma.social/pleroma/pleroma/-/issues/2867Cannot build or run stable docker image2022-05-06T14:50:35ZdashieCannot build or run stable docker imageTrying to build latest stable produce an error with the alpine repositories:
```
Step 11/17 : RUN echo "http://nl.alpinelinux.org/alpine/latest-stable/community" >> /etc/apk/repositories && apk update && apk add exiftool ffmpeg imag...Trying to build latest stable produce an error with the alpine repositories:
```
Step 11/17 : RUN echo "http://nl.alpinelinux.org/alpine/latest-stable/community" >> /etc/apk/repositories && apk update && apk add exiftool ffmpeg imagemagick libmagic ncurses postgresql-client && adduser --system --shell /bin/false --home ${HOME} pleroma && mkdir -p ${DATA}/uploads && mkdir -p ${DATA}/static && chown -R pleroma ${DATA} && mkdir -p /etc/pleroma && chown -R pleroma /etc/pleroma
---> Running in 89ec9f6bc910
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz
fetch http://nl.alpinelinux.org/alpine/latest-stable/community/x86_64/APKINDEX.tar.gz
ERROR: http://nl.alpinelinux.org/alpine/latest-stable/community: UNTRUSTED signature
WARNING: Ignoring http://nl.alpinelinux.org/alpine/latest-stable/community: No such file or directory
v3.11.13-8-gaf7d80ff31 [http://dl-cdn.alpinelinux.org/alpine/v3.11/main]
v3.11.11-124-gf2729ece5a [http://dl-cdn.alpinelinux.org/alpine/v3.11/community]
1 errors; 11275 distinct packages available
The command '/bin/sh -c echo "http://nl.alpinelinux.org/alpine/latest-stable/community" >> /etc/apk/repositories && apk update && apk add exiftool ffmpeg imagemagick libmagic ncurses postgresql-client && adduser --system --shell /bin/false --home ${HOME} pleroma && mkdir -p ${DATA}/uploads && mkdir -p ${DATA}/static && chown -R pleroma ${DATA} && mkdir -p /etc/pleroma && chown -R pleroma /etc/pleroma' returned a non-zero code: 1
```
Workaround with:
```
-FROM alpine:3.11
+FROM alpine:latest
-RUN echo "http://nl.alpinelinux.org/alpine/latest-stable/community" >> /etc/apk/repositories &&\
- apk update &&\
+RUN apk update &&\
```
But now the built image won't run:
```
Successfully built 96897a2849cd
Successfully tagged pleroma:latest
$ docker run --rm -it 96897a2849cd
standard_init_linux.go:228: exec user process caused: permission denied
$ docker run --rm -it pleroma:latest
standard_init_linux.go:228: exec user process caused: permission denied
```
Building on docker 20.10.14 on wsl2 (amd64) with `docker build -t pleroma:latest .`