webweaving: scrap and redo planning
The bot (ingame) will be used to a)record/change user passwords and b)relay infowindows to users. Additionally, admins should be able to add/drop members. The bot is also responsible for relaying queries to other bots for database replication. Bots should maintain a copy of all username, messages, news reports, department listings, whatever that could be stored in the database.
The client app should be able to a)send/receive gridmail messages, b)access the bulletin boards, c)access/submit netlog posts and comments. The client app should store the user's gridmail messages and netlog posts locally. Could store bulletin boards/other netlogs/departmental listings locally, too. Just not other users' gridmail messages. Possible direct connect chat?
Ideas: utilizing (poorly thought out replica asymmetric key encryption) to prevent storing cleartext, and so that only the proper user (or at least the one with the key) can decrypt. This doesn't necessarily preclude further obfuscation of text, but should provide a minimum level of security. Could try doing the one-time key->symmetrically encrypt text / public key encrypt->one-time key (send recipient bundled encrypted one-time key and symmetrically encrypted ciphertext).
Passwords need to be set by sending an ingame tell to one of the bots- can't be set outside of the game, so authentication is handled by the game, and the username associated with the password will be stored in the db by the bot. Won't be able to use the app to decrypt without signing in, so storing the private key with the app (outside the db) should be less of an issue.
The website should really just be a variation of the client application. Will record queries made to its own database, cache the queries made, and relay the cached queries to other client apps/ingame bots. Should display bulletin boards, gridmail, and netlogs, along with departmental directories. Password creation should only be done via ingame bot, and lost password requests should only be sent by ingame tell.
Data replication- perhaps instead of relaying IRC->tells, each app could have a script called that would add the particulars to the local queue. Have 'em listen on whatever port for requests, ignore any that don't follow whatever accepted format ends up being. This would still require resolving username to IP address, which opens up a whole 'nother can of headaches, but that's part of the fun. Could store the username/IP information in a table on the website, mirrored to other websites. Then check each one down the line if things time out.
The client app should be able to a)send/receive gridmail messages, b)access the bulletin boards, c)access/submit netlog posts and comments. The client app should store the user's gridmail messages and netlog posts locally. Could store bulletin boards/other netlogs/departmental listings locally, too. Just not other users' gridmail messages. Possible direct connect chat?
Ideas: utilizing (poorly thought out replica asymmetric key encryption) to prevent storing cleartext, and so that only the proper user (or at least the one with the key) can decrypt. This doesn't necessarily preclude further obfuscation of text, but should provide a minimum level of security. Could try doing the one-time key->symmetrically encrypt text / public key encrypt->one-time key (send recipient bundled encrypted one-time key and symmetrically encrypted ciphertext).
Passwords need to be set by sending an ingame tell to one of the bots- can't be set outside of the game, so authentication is handled by the game, and the username associated with the password will be stored in the db by the bot. Won't be able to use the app to decrypt without signing in, so storing the private key with the app (outside the db) should be less of an issue.
The website should really just be a variation of the client application. Will record queries made to its own database, cache the queries made, and relay the cached queries to other client apps/ingame bots. Should display bulletin boards, gridmail, and netlogs, along with departmental directories. Password creation should only be done via ingame bot, and lost password requests should only be sent by ingame tell.
Data replication- perhaps instead of relaying IRC->tells, each app could have a script called that would add the particulars to the local queue. Have 'em listen on whatever port for requests, ignore any that don't follow whatever accepted format ends up being. This would still require resolving username to IP address, which opens up a whole 'nother can of headaches, but that's part of the fun. Could store the username/IP information in a table on the website, mirrored to other websites. Then check each one down the line if things time out.
posted by elegiac at 3:57 AM
0 Comments:
Post a Comment
<< Home