You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Koko should use a separate table to store PM related information:
Proposed Columns
ID: An integer identifier for each message. This will be auto-incrementing, starting from 1, to allow for easy referencing and actions (like deletion).
Sender: Could be empty, a simple tripcode, or a combination of a full name and tripcode.
Receiver: Likely just a tripcode to keep things simple.
Message Content: The actual text content of the message, with support for koko's bbcode if the module is enabled. I'm not sure about wordfilter support though.
Filename: If we add support for file attachments, this field could store the filename. (If there are worries of file sharing via PMs causing trouble, the file sharing could be a setting that's disabled by default. Table should have the column anyways.)
Read Status: A boolean to track whether the message has been read by the receiver. This would allow Koko to inform tripcode users whenever they make a post with their tripcode. For example, Koko could generate a dynamic page with a notification like "You have X unread private message(s)."
I'm unsure of the best way to handle the differentiation between ordinary and secure tripcodes. One possible solution is to encode this in the very first character of the receiver field—something like a "0" or "1" prefix. This approach is inspired by binary two's complement, where the prefix (Most Significant Bit) provides a quick way to distinguish types.
The text was updated successfully, but these errors were encountered:
Koko should use a separate table to store PM related information:
Proposed Columns
I'm unsure of the best way to handle the differentiation between ordinary and secure tripcodes. One possible solution is to encode this in the very first character of the receiver field—something like a "0" or "1" prefix. This approach is inspired by binary two's complement, where the prefix (Most Significant Bit) provides a quick way to distinguish types.
The text was updated successfully, but these errors were encountered: