Search should return private rooms where the bot is already in or invited to (`world_readable`)

[bkil]

I made a private room where I invited the bot (or even have the bot joined in from the past) I expect that room search on the archive site should return this room as it is able to show its chat log.

---

See below for some background information.

If I invite the bot to a room that is invite-only but has history visibility set to public, it would be desirable to show the chat log via the web.

You may ask why this odd combination is beneficial. It's a new proposal against scammers for public groups. Anything else other than invite-only allows for spamming and flooding room state, and we proposed creating a CAPTCHA bot that would let you speak this way, while still retaining readability of the room for outsiders.

https://archive.matrix.org/r/mod-ideas:matrix.org/date/2023/06/22?at=$Y42s_vlxoOy_JRm71sKx09a8gguAgK-fKjRe29FtQXk

[MadLittleMods]

I think the current logic would work how you want if you set your history visibility to world_readable. You could also adjust the power levels in the room so people can't send messages by default until you promote them. Is this sufficient for your use case?

https://github.com/matrix-org/matrix-public-archive/blob/e4800852fff23cd4a03ef05282c71f58516cf2a4/server/routes/room-routes.js#L831-L834

Anything else seems a bit precarious to support.

Maybe, if we support a X-Robots-Tag/<meta name="robots" content="noindex, nofollow"> like thing that is being proposed in MSC4021, we could also include an explicit index directive which is mentioned in a few places but is actually not a specified directive and assumed to be a default anyway (reference)

[bkil]

Muting people based on power level won't work. The moment you allow arbitrary people joining in your room, it is vulnerable to uncontrolled join-flooding/brigading that poisons aggregate room state that is still not dealt with properly and making joins and sync slower for everyone.

We've already seen instances of this attack where they join in thousands of users per minute to your room from various HS in parallel. There can be other variations to poisoning room state, such as via invites or join-leaves.

Hence why I suggest to don't let them join in the first place.

I set history visibility to wide-open, the room to private and invited the bot, but the bot did not join the room.

[MadLittleMods]

I set history visibility to wide-open, the room to private and invited the bot, but the bot did not join the room.

@bkil I think if you try to visit the room in the archive, the bot user will try to join and may be successful now that you invited it.

[bkil]

Okay, it now worked after following a direct link. So now I have a different question. Why does the room search not return rooms that are marked as private but that could still be previewed (such as due to already having invited the bot there)?

[MadLittleMods]

Why does the room search not return rooms that are marked as private but that could still be previewed (such as due to already having invited the bot there)?

We currently are only show public rooms in the room directory,

https://github.com/matrix-org/matrix-public-archive/blob/e4800852fff23cd4a03ef05282c71f58516cf2a4/server/lib/matrix-utils/fetch-public-rooms.js#L43-L48

I think it's mainly the case that most non-public rooms won't be joinable and will lead people to 403 Forbidden

But we could change that to also show rooms which are world_readable. Mind creating a PR for that?

[bkil]

It might be wise then to groom the search result page a bit. Hits for rooms should come first that are either publicly joinable or where the bot had already joined (or was invited to). The latter part might require some shuffling with its internal state.

Then the ones with world_readable history could be listed under a different heading that explains that joining these automatically is not allowed per se, but a member is first required to invite the bot there to be able to see the log.

[MadLittleMods]

@bkil This kind of complexity isn't possible to support since the app is stateless (or efficient with the current Matrix API's).

Those kind of clarification notes would be nice but I don't see a way to effectively support that kind of thing.

[bkil]

Well, we could meet in the middle then and show world_readable invite-only rooms with a different color/decoration (and at the very end of the search results under their own heading?) with a small disclaimer that clicking this link may fail unless you have invited @archive:matrix.org to your room beforehand.

Or maybe this could be shown just on-demand when getting a forbidden response.

[MadLittleMods]

@bkil I'm open to simply, additionally showing rooms that are world_readable in the list (no complexity needed). Since the room is world_readable, the history will be accessible regardless of whether we can join the room. But we would need to adjust the archive logic to just try to use the Matrix API's first and only try to join if it fails.

I've addressed this in #272

We could additionally make the 403: Forbidden error page a lot more friendly (which should be tracked separately)