feat: add RequireInvitation registration mode for invite-link-style signups by kryoseu · Pull Request #6450 · LemmyNet/lemmy

kryoseu · 2026-04-15T22:16:26Z

Summary

Adds an invite-link-based registration system to Lemmy, giving instance admins a new way to control who can register.

New RequireInvitation registration mode — admins can set the instance to require a valid invite link for registration (alongside the existing Open, RequireApplication, and Closed modes).
local_user_invite table — stores invite links with optional max_uses, expires_at, a uses_count, and a status (Active, Revoked, Exhausted, Expired). Each invite is tied to the user who created it.
invited_by_local_user_id column on local_user — tracks who invited each user at registration time.
Three new API endpoints:
- POST /api/v4/account/invite — any authenticated user can create an invite link (with optional use cap and expiry).
- GET /api/v4/account/invite/list — list your own invitations;
- DELETE /api/v4/account/invite — revoke one of your own active invitations; returns an error if already revoked or exhausted.
Per-user invite cap — new max_invites_per_user_allowed config setting (optional u16) limits how many active invite links a non-admin user can hold at once. Admins bypass this limit.
Scheduled expiry task — the hourly scheduled task now also sets Active invites whose expires_at has passed to Expired.

Database migration

migrations/2026-04-16-000000-0000_add_invitation_table/up.sql:

Adds RequireInvitation value to the registration_mode_enum type.
Creates the local_user_invite_status_enum type and local_user_invite table.
Adds invited_by_local_user_id column to local_user.

New error types

Error	When
`MissingInviteToken`	`RequireInvitation` mode but no `invite_link` supplied at registration
`InvalidInviteToken`	Link not found, or its status is not `Active` / it is `Expired`/`Exhausted`
`TooManyInvites`	Non-admin user exceeds `max_invites_per_user_allowed`

Testing

Set registration_mode to RequireInvitation via the site settings.
Create an invite link as a logged-in user (POST /api/v3/invite). Verify the response includes a invite_link URL of the form {scheme}{hostname}/signup?token={token}.
Register a new account using the invite link. Confirm uses_count increments and invited_by_local_user_id is set on the new local_user row.
Create an invite with max_uses: 1, use it once, and verify the status becomes Exhausted and a second registration attempt returns InvalidInviteLink.
Create an invite with a past expires_at, wait for (or manually trigger) the hourly task, and verify status becomes Expired.
Revoke an active invite and confirm subsequent registration attempts return InvalidInviteToken.
Attempt to revoke an already-revoked or exhausted invite and confirm InviteAlreadyRevokedOrExhausted is returned.
Set max_invites_per_user_allowed: 2 in config, create 2 invites as a regular user, and confirm the third attempt returns TooManyInvites. Confirm an admin user is not rate-limited.
Confirm other registration modes are unaffected by this change.

Config

// How many active invite links a non-admin user may hold at once.
// Omit or set to null for no limit.

max_invites_per_user_allowed: 10

Nutomic · 2026-04-16T08:27:29Z

Very nice that you're taking this on!

So the way your code works right now is that there exists only a single, global registration token. This token can only be seen by admins, who then share it with others. It can also be used an unlimited amount of times, so if someone gets a registration token, he can register an unlimited amount of accounts.

Instead I would make it more similar to lobsters or Mastodon:

Essentially:

Every user can create invite links (full link, not only token so its easier to use)
Invites are invalidated after first use, or explicitly specify the number of uses
New optional column in local_user table indicating who invited this user (to track down accounts who invite spammers)

Optional, can be added later:

Configurable amount of invites per user and day
Some way in the API and UI to find out who invited a certain user

kryoseu · 2026-04-16T15:58:57Z

Instead I would make it more similar to lobsters or Mastodon

Nice, thanks for the detailed info, that helps.

In the approach you suggested, my understanding is that anyone would be able to create invitation links, not just admins, right?

Also, should invitation links work regardless of the registration mode (Open, Close, Require application) selected by the admin or should we add a new registration mode like Registration link, and only in which case are invitation links accepted?

Nutomic · 2026-04-17T08:34:21Z

In the approach you suggested, my understanding is that anyone would be able to create invitation links, not just admins, right?

Yes exactly.

Also, should invitation links work regardless of the registration mode (Open, Close, Require application) selected by the admin or should we add a new registration mode like Registration link, and only in which case are invitation links accepted?

Good question, I asked about that in the issue.

dessalines · 2026-04-21T14:23:22Z

Also, should invitation links work regardless of the registration mode (Open, Close, Require application) selected by the admin or should we add a new registration mode like Registration link, and only in which case are invitation links accepted?

The latter IMO. This should be a 4th type (exclusive from the others), called something like Invitation Only or Require Invitation.

The # of uses stuff is tricky. Personally I think it'd be easier to only have an expiration link (and maybe even just a default of a week), and make sure that the inviter_id: Option<LocalUserId> is tracked in the local_user table.

Every user can create invite links (full link, not only token so its easier to use)

Agree with this also, every user should be able to create invite links. The local_user_invite table could store the expiration time, and a daily job in scheduled_tasks.rs could clear out the expired ones.

kryoseu · 2026-04-21T17:42:55Z

This is the schema I have so far.

New table: local_user_invite:

 id |                       invite_link                        | creator_id | max_uses | uses_count |       expires_at       | status |         published_at          
----+----------------------------------------------------------+------------+----------+------------+------------------------+--------+-------------------------------
  1 | https://lemmy-dev.com:8536/invite/Q5b0vO1GSuKzPWPwYTx6zQ |          1 |        2 |          0 |                        | Active | 2026-04-21 10:20:29.296532-07
  2 | https://lemmy-dev.com:8536/invite/GnUmI1sVRdqOQxbUOEYxCA |          1 |          |          0 | 2026-05-20 17:00:00-07 | Active | 2026-04-21 10:20:56.21102-07
  3 | https://lemmy-dev.com:8536/invite/vv8WYx2CSni-MWaiu38cJA |          1 |          |          0 |                        | Active | 2026-04-21 10:21:09.455183-07

creator_id = LocalUserId.

Update local_site registration mode

$ curl -v -X PUT http://lemmy-dev.com:8536/api/v4/site -H "Authorization: Bearer jwt" -d '{"registration_mode": "require_invitation"}' -H "Content-Type: application/json"

< HTTP/1.1 200 OK

Register users

Using invite Q5b0vO1GSuKzPWPwYTx6zQ (which has max uses set):

$ curl -X POST -v "http://lemmy-dev.com:8536/api/v4/account/auth/register" \                                            INT ✘ 
  -H "Content-Type: application/json" \
  -d '{"username": "user1", "password": "passwordpassword1", "password_verify": "passwordpassword1", "invite_link": "https://lemmy-dev.com:8536/invite/Q5b0vO1GSuKzPWPwYTx6zQ"}'
< HTTP/1.1 200 OK

$ curl -X POST -v "http://lemmy-dev.com:8536/api/v4/account/auth/register" \                                            INT ✘ 
  -H "Content-Type: application/json" \
  -d '{"username": "user1", "password": "passwordpassword1", "password_verify": "passwordpassword1", "invite_link": "https://lemmy-dev.com:8536/invite/Q5b0vO1GSuKzPWPwYTx6zQ"}'
  < HTTP/1.1 200 OK

Invite switches to Exhausted at usage time:

lemmy=# SELECT * from local_user_invite;
 id |                       invite_link                        | creator_id | max_uses | uses_count |       expires_at       |  status   |         published_at          
----+----------------------------------------------------------+------------+----------+------------+------------------------+-----------+-------------------------------
  1 | https://lemmy-dev.com:8536/invite/Q5b0vO1GSuKzPWPwYTx6zQ |          1 |        2 |          2 |                        | Exhausted | 2026-04-21 10:20:29.296532-07

Local user has a new column showing who it was invited by:

 id | person_id |                      password_encrypted                      |      email       | show_nsfw |  theme  | default_post_sort_type | default_listing_type | interface_language | show_avatars | send_notifications_to_email | show_bot_accounts | show_read_posts | email_verified | accepted_application | totp_2fa_secret | open_links_in_new_tab | blur_nsfw | infinite_scroll_enabled | admin | post_listing_mode | totp_2fa_enabled | animated_images_enabled | collapse_bot_comments | last_donation_notification_at | private_messages_enabled | default_comment_sort_type | auto_mark_fetched_posts_as_read | hide_media | default_post_time_range_seconds | show_score | show_upvotes | show_downvotes | show_upvote_percentage | show_person_votes | default_items_per_page | invited_by 
----+-----------+--------------------------------------------------------------+------------------+-----------+---------+------------------------+----------------------+--------------------+--------------+-----------------------------+-------------------+-----------------+----------------+----------------------+-----------------+-----------------------+-----------+-------------------------+-------+-------------------+------------------+-------------------------+-----------------------+-------------------------------+--------------------------+---------------------------+---------------------------------+------------+---------------------------------+------------+--------------+----------------+------------------------+-------------------+------------------------+------------
  1 |         2 | $2b$12$hMnsOL.4w0/D6mdi5aZekO7XE.vyOu8dhOaGhdmA3VvL3WK7w1edy | user@example.com | f         | browser | Active                 | Local                | browser            | t            | f                           | t                 | t               | f              | f                    |                 | f                     | t         | f                       | t     | List              | f                | t                       | f                     | 2026-03-20 10:18:32.430561-07 | t                        | Hot                       | f                               | f          |                                 | f          | t            | Show           | f                      | t                 |                     20 |           
  2 |         4 | $2b$12$Zetmue4nKtYVZJ1y1FurMu9w4wXZG8QSSzOeHpGIwdrYoVxsWZhbS |                  | f         | browser | Active                 | Local                | browser            | t            | f                           | t                 | t               | f              | t                    |                 | f                     | t         | f                       | f     | List              | f                | t                       | f                     | 2025-09-27 18:06:32.914105-07 | t                        | Hot                       | f                               | f          |                                 | f          | t            | Show           | f                      | t                 |                     20 |          1
  3 |         5 | $2b$12$8bcE1FjFx5m19gejqtO.1OsAkLyjmS4lVgyWokLJN5k.xx8jy/4Im |                  | f         | browser | Active                 | Local                | browser            | t            | f                           | t                 | t               | f              | t                    |                 | f                     | t         | f                       | f     | List              | f                | t                       | f                     | 2025-05-03 00:08:46.176033-07 | t                        | Hot                       | f                               | f          |                                 | f          | t            | Show           | f                      | t                 |                     20 |          1
(3 rows)

At the moment I have an hourly job update_invitations_when_expired() to clear out expired invitations (i.e update their statuses to Expired that the user can see on the UI).

Nutomic · 2026-04-22T10:20:41Z

New table: local_user_invite:

You dont need to store the full invite url in the db, its enough to store the token and concatenate when returning or validating. Either way its not much difference.

creator_id = LocalUserId.

Call it local_user_id to avoid any confusion. And instead of invited_by, better call it invited_by_local_user_id even if its a bit long.

At the moment I have an hourly job update_invitations_when_expired() to clear out expired invitations (i.e update their statuses to Expired that the user can see on the UI).

Storing the status seems unnecessary. You can calculate it on demand based on the expiration date and usage count (eg when registering a new user or when returning the list of invites).

kryoseu · 2026-04-22T14:38:08Z

You dont need to store the full invite url in the db, its enough to store the token and concatenate when returning or validating. Either way its not much difference.

I had it that way, but thought storing them as links directly would help avoid having to iterate over all user invites to return in a list call or the front end having to form the URL.

Call it local_user_id to avoid any confusion. And instead of invited_by, better call it invited_by_local_user_id even if its a bit long.

Ack.

Storing the status seems unnecessary. You can calculate it on demand based on the expiration date and usage count (eg when registering a new user or when returning the list of invites).

Imo it's the more natural thing to do, rather than computing their statuses for all invites from a user in every list call.

Nutomic · 2026-04-22T19:27:10Z

Imo it's the more natural thing to do, rather than computing their statuses for all invites from a user in every list call.

It requires an extra scheduled task which is not really necessary. And the status will be wrong when the scheduled task did not run yet. Anyway Exhausted invite links can be excluded from queries, or deleted from the db.

Regardless you should push the code that you have so far, its better to review that way.

kryoseu · 2026-04-22T23:16:00Z

+  #[default]
+  Own,
+  /// all invitations, admin only
+  All,


Not sure on this tbh. Not sure it makes sense to allow admins to list all invites, unless we add an option for admins to be able to revoke any invite.

Yes this doesnt make so much sense, even on a small instance you would see hundreds of invites. Makes more sense to list invites for a specific user.

In any case I would leave all out the advanced admin functionality from this PR (except basic setting to enable invite mode). Lets finish the basic backend first, then implement the ui and after that think which extra admin features make sense.

Nutomic · 2026-04-23T11:59:52Z

  /// Data for loading Lemmy plugins
  pub plugins: Vec<PluginSettings>,
+  /// How many active invite links a user can have
+  pub max_invites_per_user_allowed: Option<u16>,


This kind of setting should go into the local_site table, so it can be changed through the admin ui without restart.

Yeah, that makes more sense.

Nutomic · 2026-04-23T12:02:52Z

+    'Revoked',
+    'Exhausted',
+    'Expired'
+);


Again the status is unnecessary, because any invalid tokens can be directly deleted from the db. And registration needs to check expires_at against current time, because the scheduled task to delete expired items might not have run yet.

Nutomic · 2026-04-23T12:05:41Z

+#[cfg_attr(feature = "ts-rs", ts(optional_fields, export))]
+pub struct CreateInvitationResponse {
+  pub invite_link: Url,
+}


This response isnt useful, clients would have to make another api call to update the list of invites. So better to return PagedResponse<LocalUserInviteView> from the create_invitation api call.

So you're saying the create_invitation should return a list of invites? So it would function similarly to the list_invites endpoint, plus the newly created invite.

Actually not, other create calls return a view for the object that was created. For example create_post returns PostResponse which contains PostView so it should be similar here.

kryoseu · 2026-04-23T16:41:26Z

Nice, thanks guys, lots of stuff to address, but I appreciate the comments.

Instead of tracking Active/Revoked/Exhausted/Expired via a status column invites are simply deleted when revoked, consumed, or expired. This removes `LocalUserInviteStatus`, `LocalUserInviteInsertForm`.status, and `InvitationListingType` from the schema and simplifies the query and API layers.

Return the full `LocalUserInvite` object from create/list endpoints instead of a pre-computed `invite_link` URL, letting clients construct the link themselves. Simplify list_invitations to pass `PagedResponse` through directly without an intermediate view wrapper.

kryoseu · 2026-04-24T17:49:51Z

+  data: Query<ListInvitations>,
+  context: Data<LemmyContext>,
+  local_user_view: LocalUserView,
+) -> LemmyResult<Json<PagedResponse<LocalUserInvite>>> {


I'm returning PagedResponse<LocalUserInvite>, which works and looks clean IMO. But need input from reviewers as it was mentioned about returning LocalUserInviteView instead, which I removed entirely in 465f05a. My understanding is that views are used when we need to join tables, which I don't think it's required for invites.

Replaces the settings.hjson config field with a proper `local_site` column so admins can configure the invite limit via the site API (CreateSite/EditSite) without restarting the server. - Add `max_invites_per_user_allowed` column to `local_site` (default 10) - Expose field in `CreateSite` and `EditSite` API structs - Read limit from DB in `create_invitation` instead of app settings - Remove `max_invites_per_user_allowed` from `Settings` struct - Update migration up/down SQL accordingly

kryoseu · 2026-04-24T18:56:52Z

Hey comrades, still going through the feedback, but I have made some changes and implemented some of the things you suggested. Please take a look and review when you have time.
One think it's still unclear to me is that need to a LocalUserInviteView instead of a LocalUserInviteQuery.

Let me know, thanks.

- Change revoke_invitation from POST /invite/revoke to DELETE invite - Move list_invitations from /invites to /invite/list - Add lemmy_db_views_local_user_invite and uuid/base64 dependencies to Cargo.lock

Nutomic · 2026-04-27T10:34:26Z

+async fn delete_invitations_when_expired(pool: &mut DbPool<'_>) -> LemmyResult<()> {
+  let conn = &mut get_conn(pool).await?;
+  diesel::delete(
+    local_user_invite::table.filter(local_user_invite::expires_at.lt(now().nullable())),


Here you can also delete rows where max_uses >= usage_count.

We're already deleting the tokens at registration time when invite.uses_count + 1 >= invite.max_uses. Adding it here would be redundant as such cases won't exist.

Nutomic · 2026-04-27T10:39:27Z

+ALTER TYPE registration_mode_enum
+    ADD VALUE 'RequireInvitation';
+
+CREATE TABLE local_user_invite (


Calling this registration_invite would be clearer in my opinion, what do you think?

IMO I prefer local_user_invite. It follows the same convention as local_user and makes the ownership clear (an invite for a local user).

The thing is that at a glance, I can misread local_user_invite as local_user_view. With registration_invite there is much less potential for confusion.

Nutomic · 2026-04-27T10:43:43Z

+      .first(conn)
+      .await
+      .with_lemmy_type(LemmyErrorType::NotFound)
+  }


This method is unnecessary as tokens are unique.

Nutomic · 2026-04-27T10:43:51Z

+    .await
+    .with_lemmy_type(LemmyErrorType::NotFound)
+  }
+}


Also unnecessary.

This method is used when revoking a user invite. If removed and delete_by_token used instead, that means any user can delete any invite, provided that they know the token, right?

Ah youre right. What you could do is read the token first and compare the user id before deleting it with delete_by_token.

Doable, but that means two queries instead of one. I can do that if you think it's better.

let invite = LocalUserInvite::read_by_token(pool, &data.token).await?; if local_user_id != invite.local_user_id { return Err(LemmyErrorType::InvalidInviteToken.into()); } LocalUserInvite::delete_by_token(pool, &data.token).await?;

The problem is that async and generic code significantly increases compilation time. These two methods probably dont make much difference, but still its probably better to have less. Instead you can make a simple helper method like:

fn check_valid_invite(invite: &Invite, local_user_view: &LocalUserView) -> LemmyResult<()> { if local_user_id != invite.local_user_id { return Err(LemmyErrorType::InvalidInviteToken.into()); } Ok(()) }

dessalines · 2026-04-29T13:53:45Z

Check CI, you might need to put some of the deps you added behind a feature gate: https://woodpecker.join-lemmy.org/repos/129/pipeline/20186/18

Also ping or unmark as draft when you want us to take another look.

Nutomic · 2026-05-04T13:17:46Z

+    query = query.filter(local_user_invite::local_user_id.eq(self.local_user_id));
+
+    let paginated_query =
+      LocalUserInvite::paginate(query, &self.page_cursor, SortDirection::Asc, pool)


Suggested change

LocalUserInvite::paginate(query, &self.page_cursor, SortDirection::Asc, pool)

LocalUserInvite::paginate(query, &self.page_cursor, SortDirection::Desc, pool)

Nutomic · 2026-05-04T13:22:00Z

+      .first(conn)
+      .await
+      .with_lemmy_type(LemmyErrorType::NotFound)
+  }


This methid is only used for pagination. You can remove it and use read_by_token for pagination instead.

Good call out, thanks.

dessalines

Also check merge conflicts.

dessalines · 2026-05-04T20:33:04Z

Looked over again, and I think the admin list invites endpoint is still missing.

kryoseu · 2026-05-05T01:47:07Z

Looked over again, and I think the admin list invites endpoint is still missing.

I was under the impression this wouldn't add much value at this point, unless we implement APIs to allow admins to also revoke any invite, etc. If we decide to do so, I could do this in a subsequent PR, if that's okay.

But imo I think more importantly would be for admins to be able to see list of users and who they were invited by.

- Replace `is_active()` check with `is_expired()` in registration: exhausted invites are deleted on use, so only expiry needs to be checked at read time - Remove `is_active()` helper as it's no longer needed - Remove unused `read()` by ID; switch pagination cursor from integer ID to invite token via `CursorData::new_plain - Change invite list sort to descending (newest first) - Add unit and integration tests for `is_expired`, `get_invite_url`, CRUD operations, and `uses_count` updates

Nutomic · 2026-05-05T09:35:54Z

The admin functionality can be added later, otherwise this PR will get too complex. In principle this is ready to merge. However I want to hold off a bit longer, because we will publish the first beta version of 1.0.0 in the next few days.

Anyway you can already start to work on the corresponding frontend changes. For that clone the lemmy-js-client repo, run ./scripts/copy_generated_types_from_lemmy.sh and make a PR with the generated changes. Then we will publish a test version of the js client which you can use in lemmy-ui.

dessalines

This is good for now, we might have to make tweaks as we work on the front end anyway.

As @Nutomic said, we might wait for a few days to merge this, when we plan to get a lemmy beta out (without this included).

kryoseu requested review from Nutomic, dessalines, dullbananas and phiresky as code owners April 15, 2026 22:16

kryoseu force-pushed the feat/registration-token branch 4 times, most recently from dd73567 to f2e0575 Compare April 16, 2026 01:05

kryoseu marked this pull request as draft April 16, 2026 16:08

kryoseu force-pushed the feat/registration-token branch from dc5d1b6 to 61266f6 Compare April 16, 2026 16:14

kryoseu changed the title ~~feat: add registration token mode for invite-link-style signups~~ feat: add RequireInvitation registration mode for invite-link-style signups Apr 22, 2026

feat: add invite link registration

0f257da

kryoseu force-pushed the feat/registration-token branch from 035feb4 to 0f257da Compare April 22, 2026 23:06

kryoseu commented Apr 22, 2026

View reviewed changes

kryoseu added 4 commits April 22, 2026 16:20

fix: remove redundant invite status check

9a95334

fix: format

5f6aa9b

fix: remove unwrap from get_invite_url and propagate errors

3355031

fix: remove dependency not used

b6280af

Nutomic reviewed Apr 23, 2026

View reviewed changes

Comment thread crates/routes/src/utils/scheduled_tasks.rs

Nutomic reviewed Apr 23, 2026

View reviewed changes

kryoseu added 4 commits April 24, 2026 08:24

Merge remote-tracking branch 'upstream/main' into feat/registration-link

2f9b358

fix: remove dependency not used

b0dfeaf

kryoseu commented Apr 24, 2026

View reviewed changes

refactor: update routes for invite endpoints

c719489

- Change revoke_invitation from POST /invite/revoke to DELETE invite - Move list_invitations from /invites to /invite/list - Add lemmy_db_views_local_user_invite and uuid/base64 dependencies to Cargo.lock

Nutomic reviewed Apr 27, 2026

View reviewed changes

kryoseu added 2 commits April 28, 2026 22:50

refactor, tests and migrations

0e4c988

remove unused dependencies and invite delete function

8904b68

kryoseu added 2 commits May 1, 2026 15:14

Merge remote-tracking branch 'upstream/main' into feat/registration-link

c83e93e

Refactor invite revocation and fix conditional import

9ba0ca6

kryoseu marked this pull request as ready for review May 2, 2026 04:03

Nutomic reviewed May 4, 2026

View reviewed changes

dessalines reviewed May 4, 2026

View reviewed changes

Merge remote-tracking branch 'upstream/main' into feat/registration-link

f0567fb

kryoseu added 2 commits May 4, 2026 20:34

fix: test case

e560db9

add comment on admin check for invite creation

7c514d5

dessalines approved these changes May 7, 2026

View reviewed changes

	LocalUserInvite::paginate(query, &self.page_cursor, SortDirection::Asc, pool)
	LocalUserInvite::paginate(query, &self.page_cursor, SortDirection::Desc, pool)

Uh oh!

Conversation

kryoseu commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Database migration

New error types

Testing

Config

Uh oh!

Nutomic commented Apr 16, 2026

Uh oh!

kryoseu commented Apr 16, 2026

Uh oh!

Nutomic commented Apr 17, 2026

Uh oh!

dessalines commented Apr 21, 2026

Uh oh!

kryoseu commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Update local_site registration mode

Register users

Uh oh!

Nutomic commented Apr 22, 2026

Uh oh!

kryoseu commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nutomic commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nutomic Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kryoseu commented Apr 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kryoseu commented Apr 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kryoseu Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kryoseu commented Apr 15, 2026 •

edited

Loading

kryoseu commented Apr 21, 2026 •

edited

Loading

kryoseu commented Apr 22, 2026 •

edited

Loading

Nutomic commented Apr 22, 2026 •

edited

Loading

Nutomic Apr 23, 2026 •

edited

Loading

kryoseu Apr 27, 2026 •

edited

Loading