Opting Out

[Sleuth56]

Has there been any thought given to how a room admins or homeserver admins could opt out their room or server? My thought would be some sort of state event in a room and the already standard X-Robots-Tag for servers.

I know this project is in very early stages but given the distributed nature of the matrix network I believe this to be a very important thing, especially coming from the matrix core team (Or at least that's who it looks like it's being driven by).

---

Related MSC's:

• MSC2291
• MSC4021

[MadLittleMods]

The archive will only access rooms where the history is world_readable. A room can be public without world_readable history so there is already mechanism to sorta control this.

But it is possible that we add an additional signal/control to determine whether search engines should index it. I imagine that you would still be able to access the room via Matrix public archive but we would tell Google not to index the room if that signal is present.

[Mikaela]

Will removing world readability effect the archive or will the past history still be visible using it?

Is there any mechanism in Matrix for redacting the past public history that any room administrator can use without resorting to running bots/servers or unspecced hacks (m.room.retention and specced changing history visibility to members only and /upgraderoom 10)

[Mikaela]

Another concern is do tombstoned rooms automatically get excluded by both this and matrix-static? They may be inaccessible if they have weird join rules and no one to invite.

[MadLittleMods]

Will removing world readability effect the archive or will the past history still be visible using it?

@Mikaela I'm not sure exactly how the m.room.history_visibility lookup will happen exactly (current state or state at the time). It depends on that.

Is there any mechanism in Matrix for redacting the past public history [...]

Best to create an issue and ask elsewhere about this.

Another concern is do tombstoned rooms automatically get excluded by both this and matrix-static? They may be inaccessible if they have weird join rules and no one to invite.

Any world readable rooms, including tombstoned will be accessible. I don't have any details about the other project, matrix-static, for how it works around this.

[MadLittleMods]

Related to https://github.com/matrix-org/synapse/issues/14127

[Cyberes]

I have a few rooms that are set to world_readable and published to my homeserver's room directory that I don't want to be on my public archive site. My solution was to simply ban the archive bot from those rooms. This really isn't a good solution because the rooms are still listed and when you try to view them you get an error page.

What if the archive backend was to query all the rooms to check if its bot has access? If it is banned from a room then it would remove that room from the list on the website.

I imagine this check would be in addition to whatever setting is used to opt-out.

[MadLittleMods]

@Cyberes The app is stateless so we can't just hold onto that kind of access/ban information across requests. It needs to be something we can query from the API and for the room directory, we wouldn't want to make a separate look-up for every single room we're trying to display in the grid so it needs to come from the room directory, /publicRooms endpoint.

A new state event like X-Robots-Tag/<meta name="robots" content="noindex, nofollow"> that the issue description mentions seems like a good way to go. The room directory can relay this information just like it already does for join_rule and world_readable. A new MSC needs to be created for this though.

---

If you can share the details, what's the distinction that your rooms should be public, world_readable but not accessible in the archive? Trying to understand the context/use-case.

[Cyberes]

The rooms that fit the public world_readable but excluded from the archive are all related to "server administration" such as announcements, the room for things relating to the homeserver, etc. It's fine if a user from another HS finds and joins those rooms but I'd rather not have their content public on the internet (you know what they say, "the internet never forgets" or whatever).

[paul90]

Really not sure about how fit for purpose using public world_readable is as a basis for inclusion in the archive. I'm going to assume that world_readable equates to Anyone in the Room Security & Privacy options in Element. So, if you want people to see content before joining the room it will get archived.

Changing the setting to Members only (since the point in time of selecting this option), but doesn't change the visibility of existing history. And, if @archive:matrix.org is still a member of the room?

At least for now, banning the bot seems like the only solution, but the resulting 403 is really doesn't look good for the archive.

[Mikaela]

So apparently when room is publicly joinable and only showing history for members, it may show history on archive.matrix.org for the first one who tries to access it, until a Draupnir/Mjolnir triggers and bans the bot which will stop subsequent visits to the page?

• https://matrix.to/#/%23furrytech%3Amatrix.org/%24IifH_2lqoP2raQ7wUSMZWBIWFvSRrSuHkyEKj9HONpM?via=777.tf&via=matrix.org&via=tedomum.net

[tulir]

After the bot joined a room with history visibility set to joined, it rightfully showed an error on the website. However, the error says

StatusError: 403 - Only world_readable or shared rooms that are public can be viewed in the archive.

shared rooms should not be archived, only world_readable rooms should be.

[MadLittleMods]

shared rooms should not be archived, only world_readable rooms should be.

"archived" is a bit of a overloaded term here but given that this project is called "Matrix Public Archive" I can see where the confusion may be be coming from. Any public room with shared/world_readable history visibility should be viewable in Matrix Public Archive. The idea is if a random Matrix user can view the room, then it should be viewable in the archive. But only history_visibility: "world_readable" rooms are indexable by search engines.

The Matrix Public Archive doesn't hold onto any data (it's stateless) and requests the messages from the homeserver every time (it archives nothing). The archive.matrix.org instance has some caching in place, 5 minutes for the current day, and 2 days for past content.

I've tried to clarify more of this in the FAQ document and added more details on why not guest access/peeking.

Banning @archive:matrix.org will prevent the room from showing up on archive.matrix.org and the cache will expire after 5-minutes/2-days for any content that is showing there now. Adding better opt-out controls like this issue is discussing is on the list :+1:. I've updated the description with the current MSC proposals out there.

[bkil]

Related: #257

[bkil]

Why was my comment marked off topic?

But also, it was not obvious to many of us that this project aims for 5 minutes/2 days ephemeral caching.

According to the documentation and the name, most users seem to associate it with some kind of crawling mass-joining bot with unlimited storage and resources that slows the federation to a crawl and eternally captures all of their content to use against them or train a mastermind that will take over the world.

Many moderators are also suffering from PTSD due to encountering unidentified bots almost every week mass-joining basically every room they can and about half of them start to flood or spam thousands of rooms at a time after a few days of delay.

This bot and the system itself falls under a different category as long as it is true that it is an interactive agent acting on behalf of a given human visitor who is browsing the calendar or clicking on a permalink they got from another platform. This would be seen highly beneficial and a quality of life improvement by most. That would be much more palatable to all stakeholders. If this was true, the spirit of the robots.txt exclusion standard similarly wouldn't apply.

I recommend renaming the project to something that makes this more obvious, such as matrix-static-proxy, matrix-nojs-preview, matrix-nojs-reader, matrix-nojs-client, matrix-ssr, server-rendered-rooms, matrix-permalinker, matrix-permalink-resolver, ...

I seems logical and uncontested that we should allow crawling & indexing of a message by search engines as long as it is linked this way from a personal web page. However, enabling spidering (following intra-site links with indefinite scrolling) again falls under a different philosophical debate as can be seen from the relevant MSCs.

[MTRNord]

Just an additional data point but is it considered that it may be a bad idea to allow anyone to activate this on any room? Shouldn't it be a thing only room admins can do? Basically because a) a room admin may not be aware of this b) a room admin may not want this but also doesn't want to clutter state with yet another ban.

Another thing is the right to be forgotten which exists in the eu. A user has the right to be forgotten as per gdpr. It's not clear how an individual can opt out even if the room itself is deciding to allow the bot. Mass redactions in the past have been the equivalent of a denial of service attack. So I don't think they are a sensible way to do this.

[bkil]

@MTRNord Could you please read the past messages? Or at least mine https://github.com/matrix-org/matrix-public-archive/issues/47#issuecomment-1570861030

[MTRNord]

@MTRNord Could you please read the past messages? Or at least mine https://github.com/matrix-org/matrix-public-archive/issues/47#issuecomment-1570861030

I don't see how your message is in any way relevant to my question? It displays contents and Google can crawl it. Clearly my questions apply. No matter the name of it. It's not the point I was making.

Especially the right to be forgotten is not covered by prior messages. Banning Was considered the only way to opt out. As well as the msc. Which both only admins can use. This is not something a regular user can use.

[MTRNord]

Additionally @bkil going by the statement of you and the prior explanation of how this works by @MadLittleMods shouldnt the whole thing be opt in based on admin decission rather than opt out? (that's basically the tldr of my first part of my initial question)

[bkil]

@MTRNord It is already opt-in. You opt-in by making your room world-readable.

[MTRNord]

@MTRNord It is already opt-in. You opt-in by making your room world-readable.

No that's not how opt in works. That setting doesn't mention this service so the opt in is not for this service but for the world readability of your matrix room. Those are 2 very seperate things.

If this indeed is supposed to be the way to opt in this MUST be in matrix spec and in the ui of clients. Otherwise this is purely hostile.

The setting gives only consent for a very specific thing. And that consent wasn't given to a third party service.

[bkil]

The default room creation dialog recommends private access. If you deliberately make it public, you are signalling consent.

If you select the public join rule here, the created room will by default have history access set to Members only (since the point in time of selecting this option). You still need a specific admin action to enter the room settings and change this to world readable, that could actually be considered a second opt-in action.

As per my comment, this is effectively meant to be considered a nojs matrix client, hardly a third party service. Could we take this talk to a specific matrix room perhaps if you have any further question?

[bkil]

Furthermore, although only a few web scrapers support running limited JavaScript for a few seconds as of now, what kept either a deep pocket existing player or a new startup in the future from running scripts for much longer duration of time and with greater compatibility?

It would not be that much of a barrier for them to then bump into matrix.to links that could lead them to opening matrix rooms via web clients either after automatically joining with a guest account or by using the established room preview button.

[MTRNord]

I consider this discussion a lost hope and decide to not further engage with bkill and wait on other opinions instead :)

[Porkepix]

But also, it was not obvious to many of us that this project aims for 5 minutes/2 days ephemeral caching.

I'd be curious where do you take that from; I discovered that issue from the blog article explaining the feature-parity with Gitter. Whether it is that article or the README from this repo, it is pretty clear it want to reproduce Gitter's operation, which was a complete indexing of the content.

If that would be the case, it changes a lot of things on how people interact and use such a tool when you know that everything you say will be hard written and searchable by anyone for the years to come, which would require at the very least to clearly inform people (slightly out of topic, but in the same time on-topic: this is the same kind of issues when Matrix offer server-side logs for irc channels where users wouldn't expect this to exist). For my part this is the exact reason for which I never used Gitter. I don't intend for a chat to log and make it available to search engines everything I say.

I'm following the issue for some time now (since the blog article), but didn't knew where to raise the question: I clearly agree with @MTRNord this would need to be an opt-in rather than opt-out, and duly inform people about this.

As for your latest remark @bkil: Technically nothing prevent that. Ethically and legally on the other hand, yes.

[tulir]

You still need a specific admin action to enter the room settings and change this to world readable, that could actually be considered a second opt-in action.

@bkil note that you currently you don't have to make the room world readable, so creating a publicly joinable room is opted in by default. See #239

[Mikaela]

@Porkepix

But also, it was not obvious to many of us that this project aims for 5 minutes/2 days ephemeral caching.

I'd be curious where do you take that from; I discovered that issue from the blog article explaining the feature-parity with Gitter. Whether it is that article or the README from this repo, it is pretty clear it want to reproduce Gitter's operation, which was a complete indexing of the content.

It was mentioned at Matrix by @MadLittleMods

• https://matrix.to/#/%23matrix-public-archive%3Amatrix.org/%24h2Z66FeNtc5B3Ps38ZVC8rvjTgojf_IWFEpAxF797-s?via=matrix.org&via=element.io&via=evulid.cc

It was also added to the FAQ

• https://github.com/matrix-org/matrix-public-archive/blob/main/docs/faq.md#why-does-the-archive-user-join-rooms-instead-of-browsing-them-as-a-guest

[Porkepix]

@Porkepix

But also, it was not obvious to many of us that this project aims for 5 minutes/2 days ephemeral caching.

I'd be curious where do you take that from; I discovered that issue from the blog article explaining the feature-parity with Gitter. Whether it is that article or the README from this repo, it is pretty clear it want to reproduce Gitter's operation, which was a complete indexing of the content.

It was mentioned at Matrix by @MadLittleMods

* [matrix.to/#/%23matrix-public-archive%3Amatrix.org/%24h2Z66FeNtc5B3Ps38ZVC8rvjTgojf_IWFEpAxF797-s?via=matrix.org&via=element.io&via=evulid.cc](https://matrix.to/#/%23matrix-public-archive%3Amatrix.org/%24h2Z66FeNtc5B3Ps38ZVC8rvjTgojf_IWFEpAxF797-s?via=matrix.org&via=element.io&via=evulid.cc)

This link end up with an error and just showing the chan, explaining that

Failed to load timeline position Tried to load a specific point in this room's timeline, but was unable to find it.

The idea is if I can view the messages from a Matrix client as a random user, I should also be able to see the messages in the archive.

Keep in mind that only rooms with history visibility set to world_readable are indexable by search engines. The Matrix Public Archive doesn't hold onto any data (it's stateless) and requests the messages from the homeserver every time. The archive.matrix.org instance has some caching in place, 5 minutes for the current day, and 2 days for past content.

This is unclear to me, but as I understand it, the archive doesn't store, but when the bot crawl, it's relaying everything to the crawler, let's say Google. Which in turns mean that while the Archive server, indeed, doesn't store anything but cache, Google is. And I think it's the point here, that this shouldn't be a default behavior and should absolutely be advertised in a very visible way to users.

Users with personal log is a thing, available logs when you join is another already exposing much more. Have those logs crawled and indexed allowing anyone to search in them globally for who knows how much time is even another, on a much different scale with much different consequences.

[bkil]

Odd that you single out Google, as they are actually the good guys here. All better search engines periodically recrawl and validate their index and remove stale entries, especially ones where your server returns 3xx or 4xx. Those that also host a web cache for their search results (instead of implementing a live proxy) will also purge the respective entries in such cases.

What you should be actually worried about is archiving services finding such links, because taking those down should usually be considered impossible for one who is not the owner of the given crawled portal but just a "commenter":

• https://github.com/bkil/freedom-fighters/blob/master/en/service/web-cache-archive.md#user-content-mementoweb

[Mikaela]

Odd that you single out Google

https://en.m.wikipedia.org/wiki/Google_(verb)

[Porkepix]

Odd that you single out Google, as they are actually the good guys here. All better search engines periodically recrawl and validate their index and remove stale entries, especially ones where your server returns 3xx or 4xx. Those that also host a web cache for their search results (instead of implementing a live proxy) will also purge the respective entries in such cases.

Whether you think they're good guy or not here because some of their practices here would be better misses the point: for the server to return 3xx or 4xx means the content was removed. So unless people develop tools to removed all of their messages in short time after they were written (which might well be the solution here…), they'll still be available at anytime on whatever search engine or archiving services you prefer that crawls it and offer that to anyone with a search interface. Google was the easy name to throw here being massively the most used in most countries, but that apply to anything else.

[bkil]

@Mikaela I mean, I'm using quite a few web search engines in parallel and I do see some that are updated within minutes but also others that have indexes that are many years old. (Yes, kind of weakening my point here :wink: ) The big players are usually the better ones in this respect according to my stats.

[bkil]

Let me try to elaborate here about #47 and #239 so I don't overload the issue tracker:

• https://archive.matrix.org/r/securemessagingapps:matrix.org/date/2023/06/01?at=$AEeGOiIiO_D05qnjIW0Ninx501xznY1y2LalOOsi52Q

[MTRNord]

Let me try to elaborate here about #47 and #239 so I don't overload the issue tracker:

• https://archive.matrix.org/r/securemessagingapps:matrix.org/date/2023/06/01?at=$AEeGOiIiO_D05qnjIW0Ninx501xznY1y2LalOOsi52Q

Hm I fail to see how that's in any way on topic here. Especially since none of your accusations seem to be applicable to users in this issue or the pr. 🤔 Also as repeated earlier you still don't seem to understand the basic definition of consent. Just because you give consent to thing A doesn't mean you give it to thing B just because thing B uses the same Api. And in matrix specifically having a way to fine grain this was an afterthought. Just because I made a room public 4 years ago doesn't mean I am agreeing to service X in 7 years. That's not possible since I can't know about such a service. Hence such service can't have consent unless given explicitly. You can't inherit consent from a setting you choose to use. Consent works by having a dedicated "I agree with this service" button. And it's applying to all services. Not just the archive. If let's say a John Doe comes around making an archival service that allows you to print a postcard of any room with public readable on matrix doesn't mean that this service has consent from the user to do that. That thing is commonly known as "abuse" or "abusive behaviour" since you claim to have consent while not having any.

Edit: typos fixed.

[MadLittleMods]

Even as it stands today, the Matrix Public Archive is respecting history visibility. For public rooms with shared history visibility, you can only view the content just like any other random Matrix user. For world_readable rooms, we allow search engines to index content at their discretion. This is pretty inline with what the spec says about world_readable regardless of the context or type of client:

• world_readable - All events while this is the m.room.history_visibility value may be shared by any participating homeserver with anyone, regardless of whether they have ever joined the room.
  • shared - Previous events are always accessible to newly joined members. All events in the room are accessible, even those sent when the member was not a part of the room.

-- https://spec.matrix.org/v1.6/client-server-api/#room-history-visibility

This issue is meant to be tracking better ways to control the display and indexing behavior which are being explored with things like MSC4021.

Please be mindful that the long-winded discussions and repeated replies don't increase clarity.

[Mikaela]

Even as it stands today, the Matrix Public Archive is respecting history visibility.

I would argue that it's not respecting shared to room members-only. It's non-consentually resharing what happens in the room to unknown parties, although those would be free to join Matrix properly (or even follow the guest access rules) to get the history shared.

[tsmethurst]

Why is this opt-out and not opt-in, you creeps. Come on.

[n0toose]

Hi, I previously deleted a comment which I thought that was too harsh given the context, as the concerned channel was apparently visible to guests too and that it did not concern "Members only" options.

I am reposting it with some small amends, as it apparently does not respect "Members only" options either:

---

Hi, I apologize if the tone sounds harsh, but I believe that the default behavior of this robot has been disruptive to one project that I participate in and that I and others are not at fault here and we have better things to do.

Most channels don't have guest access for the same reasons that only a fraction of IRC channels did; "everything is searchable on Google" can change some peoples' behavior. It's a sane opt-in default that leads to an explicitly defined behavior, I am not sure why you'd have the bot not maintain that behavior.

Not only does it essentially emulate a behavior that's disabled as a sane default at a greater and more organized scale without e.g. asking admins if they want to enable that, but it's also explicitly not clear if we can kick it out and invite it later back in if we decide that we actually do want it. The design right now is, in my honest opinion, very user-hostile and I would think that this was being done by a very malicious party if this repository was not under the matrix-org namespace.

It is obvious that no admins of the rooms you're talking about were consulted whatsoever, so you just essentially actively made that decision for them while circumventing the due procedures of a specific community. Lowering the barrier of just joining the channel (there's already a setting for that, and it doesn't have anything to do with world readability!) out of nowhere is dangerous (edit: more dangerous than it previously was) and can amplify campaigns of targeted harassment against small-to-medium-sized communities. Any hypothetical abuse vector used as an excuse to justify the current behavior of this bot is not comparable, as it presumes esoteric knowledge on the end of a user and removes the capacity to detect brigading campaigns through suspicious join events.

Like, I get what you're trying to do with this, but this would seriously be fixed if you just sent a message to the admins or in the room explaining the situation and asked them if they wanted to opt-in or something (or actually respected the settings of a channel); this is just absolutely awful.

[n0toose]

I want to never, ever, ever feel the need to write an entire essay to this organization for something that should be obvious to an organization developing infrastructures for communities and open-source projects.

No matter if you think that you can implement it in a way that is better / more ethical, the existence of a service joining channels out of nowhere (while letting everyone else try to put the pieces together as to why it exists, how it joined, did somebody invite it?, etc.) wastes time of volunteers using Matrix to figure out what changed in their channel and what implications it may have.

There's a clear power imbalance, you have the matrix.org infrastructure that cannot have any accountability whatsoever and are also being paid to clean the entire thing with the "move fast, break things" approach. On the other hand, you have a lot of volunteer-run communities that depend on you and have to figure out what's going on with their channel with zero communication whatsoever. I spent at least 2 hours of limited, volunteering time examining what was happening, and there were more people involved (EDIT: Just to be clear, this is a strictly personal opinion and I do not speak for them.).

Discord uses announcements to explain changes in the way people run their communities. You can announce stuff server-wide in IRC. The UX problems that exist in Matrix are not the fault of the communities that use your infrastructure and the "move fast, break things" approach to this is in every way super annoying, especially with the Trust & Safety implications that were dismissed with a series of whataboutisms.

[Mikaela]

Do I understand correctly that the whole XMPP protocol is also opted-in to the bot with no method of opting out?

• https://archive.matrix.org/r/xmpp_xsf_muc.xmpp.org:matrix.org

[MTRNord]

I had just another thought about this:

Would it help any admins or in general if the bot instead of silently joining would announce what is happening and link to its privacy policy as well as the FAQ? Currently, it joins silently, which feels like intentionally wanting to stay under the radar, even if that's not intentional. I think at least in some cases having the bot explain itself might help with acceptance and also allows room admins to more easily and quickly opt out if they wish to do so.

[akierig]

Hi I'm a Libera channel op and my channels' policy is to kickban anyone with [m] in their nick. Matrix bridges with their "we remember everything forever by default" are bad enough, this is just appalling and I agree with most of @n0toose's comment above, depending on one's view of the matrix.org/element organization

The design right now is, in my honest opinion, very user-hostile and I would think that this was being done by a very malicious party if this repository was not under the matrix-org namespace.

I'd also point to Libera's own public logging policy: https://libera.chat/policies/#public-logging

Some projects may wish to log their channels publicly, if you do so the logging should be authorised by the channel owners and users in the channel should be notified (through for instance the topic, entry message, or similar) that public logging is taking place. Channel operators should consider ways for users to make unlogged comments and a process for requesting the removal of certain logs.

If you operate a service that scrapes internal channel content or published logs, ensure that you have obtained permission to do so from Libera Chat staff or the channel owners before you start scraping data, also make sure that there is an easy way for channels to opt-out.

If you wish to publish logs of a single conversation, please make sure you have gotten permission from all participants before doing so.

[JokerGermany]

Hi I'm a Libera channel op and my channels' policy is to kickban anyone with [m] in their nick. Matrix bridges with their "we remember everything forever by default" are bad enough, [...]

And what do you want in a matrix related Issue? It looks like you are hostile against Matrix. Kickban anyone with [m] in their nick is your choice, but it's wierd that you are commenting matrix project which you seems to hate...

[Porkepix]

Hi I'm a Libera channel op and my channels' policy is to kickban anyone with [m] in their nick. Matrix bridges with their "we remember everything forever by default" are bad enough, [...]

And what do you want in a matrix related Issue? It looks like you are hostile against Matrix. Kickban anyone with [m] in their nick is your choice, but it's wierd that you are commenting matrix project which you seems to hate...

Whether they hate it or not is a thing, and I won't comment on this. But it's completely legitimate even for non-users to comment on such matters considering due to the various bridging here and there even non-users are affected by things such as public logs available to everyone, or public indexing/crawl/scrapping resulting in logs that can be searched for in search engines.

Ie. a pure IRC user with many matrix user that joined their channel (and you can translate that to XMPP or pretty much any other protocol Matrix is bridging to) is completely affected by these choices, pretty much against their will by design (not even talking about all the users who're not even aware about this).

[akierig]

And what do you want in a matrix related Issue?

This effects me because I participate in IRC networks that matrix bridges to. I never opted in to being archived publicly by Matrix, nor do I want to be.

[MadLittleMods]

@akierig It looks like the libera.chat rooms have history visibility set to joined which means the rooms won't be accessible in the archive at all (will just give a 403 Forbidden).

The archive bot will still join the room because it doesn't know the history visibility before it joins but it won't show any content from the room in that case (only world_readable and shared history visibility are accessible in the archive). If the public room is in the room directory, it will be listed in the archive but will still lead to a 403 Forbidden in that case.

It seems useful if we had an endpoint that would return the history visibility information without joining (GET /_matrix/client/v3/directory/list/room/{roomId} currently only returns whether it's in the room directory or not) . It would need to take a roomIdOrAlias instead to be useful though as that's the beauty of POST /_matrix/client/v3/join/{roomIdOrAlias} right now. It would also be nice to hide these rooms from the archive homepage as well which means /publicRooms would need to show the history visibility beyond the world_readable indicator it has now.

[Mikaela]

I would like to request increasing the priority for resolving this issue as there are currently at least two instances of bot requiring manual banning:

• @archive:matrix.org
• @archiver:gitter.im
• @matrix-public-archive:evulid.cc

Additionally I suspect the following of being matrix-public-archive instances:

• @archive:privacyguides.org - I have no idea where its web interface is, but the homeserver admin is @jonaharagon who is active on this issue tracker and hasn't gotten back to requests for comment at Community Moderation Effort (or PrivacyGuides moderators haven't reported back hearing anything about him).
  • Confirmed as an instance, but tied to specfic rooms. https://github.com/matrix-org/matrix-public-archive/issues/47#issuecomment-1580967650

[jonaharagon]

@Mikaela oops, I didn't see a question in CME. I do have this set up, but my instance can only join two specific rooms (which I admin), so it is not contributing to this problem.

[Half-Shot]

For what it's worth, we've had to ban the archive bot on the bridge because it joined too many rooms. The IRC bridge (at least, the libera.chat bridge) requires that all Matrix-side users are joined to the IRC channels they are bridged to.

However, most IRC networks will limit how many channels one user may join at any time. The bot exceeded this value and the result was the bridge became very unstable. We're hoping there might be a solution to this problem at some point because I believe the archive provides value to some users of the bridge, but ultimately in it's present incarnation it's not suitable.

[Mikaela]

As there is even more development with opting more rooms into archiving, I would like to ask whether there is development also with opting out?

I also wonder whether this issue could be pinned for its significance? This tracker doesn't currently utilise that feature and three can be pinned at once on GitHub as far as I am aware of.

Additionally I have been wondering whether declaring Free Tibet and Slava Ukraini in public rooms gets them opted out from Baidu and Yandex?

[Mikaela]

I just learned that https://staging.archive.matrix.org/ is a thing and using a separate account @archiver:gitter.im and I find it upsetting that it's not mentioned anywhere and is again more whacking a mole while you could be better and allow rooms to just opt out of this "service".

You could be even better and be opt-in for room administrators which would be in spirit of privacy friendliness without even mentioning modern privacy legislations or directives.