Unblock-zh Roadmap

Roadmap

1. Better MWAPI Integration

1. Fetch blocked status of the username and IP address provided, and add this information somehow to the ticket

• this should ideally trigger asynchronously as a job after the ticket goes into the database
• this should be rate-limited, so a massive flood of tickets will drop some of the jobs
• this could be implemented via the hidden special tags system
• //t/remote_action/get_block/cur_name/+Bluedeck --> //t/block_status/user/+UNAME?e=20241231&id=118117&a=JIMMY_ABOT&s=SUMMARY
• //t/remote_action/get_block/ip/+127.0.0.1 --> //t/block_status/ip/+IP_ADDR?e=20241231&id=650391&a=JIMMY_ABOT&s=SUMMARY

2. Automate account creation and IPBE right granting via UNBLOCK_ZH_ORG_BOT so admins can perform both with a click of a button

• Maintain credentials for the bot
• Apply privileges for the bot
• Impose rate-limit on actions, per local admin (?)
• Localize (mux) edit summaries per project (remote project / local namespace)

2. Rich form response

1. Create a number of new special tags, such that when they're present, the user reply prompt is modified.

• Tag `/rich_response/ip` => displays an IPBE radio button cluster in addition to the normal reply prompt
• Tag `ChooseNewName` => displays a new username selection prompt (to replace the old invalid username)

3. Architectural change to accommodate more heterogeneous user groups

• Match UI elements to the specific permissions per each group
• `session-heartbeat` api should return a list of implied permissions based on the current group status in each namespace
• Presence of UI elements should be derived from permission list instead of group list

4. More search modes

• Add the following privileged search modes
  • Search by the first few characters of a ticket number (via SQL `linkname LIKE 'ticketnumber%'`)
  • Search all tickets with the same email address (via hidden special tag `//t/email/+...`)
  • Search all tickets recently closed by a certain user (via freeform tag `closed`)
  • List of recently viewed tickets
    • This can be implemented as a server-only special tag `#viewed/{uid}`

5. Infinite scrolling

6. Leaderboard

• Could be implemented either via the special tags system, or the server-only tags system.
• Simply count the number of `closed` tags added by a certain user on channels from a certain namespace.
• Periodically, reduce the real time data down to a number in the database.

7. Server-only special tags

A new set of special tags that are never returned to the client (except to those with permission `chan_tags_inspect_server_only`), which influences the channel behavior, and serve as extra indexes.

8. SES integration

Sign up for an SES key to automate email notifications

9. Maxmind IP Geolocation database

Ocaml or rust parser of maxmind geolocation database and transform into a fully indexed searchable geolocation sqlite db accurate to country level.

1. Display special notices if IP originates from China or Hong Kong
2. Automatically add `/sched/scrubip` tags to tickets with IP address originating from the above regions.

Tag table: Compare and contrast

Method 1: tags table remains `tag_only`, so every detail goes into a btree index. The `+` delimiter delimits the data section, no special character is allowed since the need to index by tag remains.

Method 2: tags table gains an additional `data` column. Create Unique Index ... on tags (..., tag, data, ...); The data is still indexed, but partial index with just tags exists. The data portion allows any unicode characters so unicode shenanigans are possible, and exacerbated because a unique index implies uniqueness which maybe bypassed by unicode fuckery.

Method 3: The `data` column is not indexed and is textual. CJK characters are allowed and unicode shenanigans remain possible, but no unique index to complicate the problem.

Method 4: The `data` column is not indexed and is binary. Allows for ns encoding and binary data. Unicode shenanigans are irrelevant since a) not indexed, b) binary

Method 5: The `data` column is indexed and textual, but the unique constraint only applies to the actual tag. (This is disallowed: [`tag+data`, `tag+data2`]). This makes unicode shenanigans slightly less relevant since bypassing unique constraint by altering the data portion is now infeasible. However, when searching for the whole tag, unexpected mismatches might arise if unicode trickery is not accounted for.