webweaving: wonking out more codey code code designs

Each client app doesn't actually need the full database, just the user's mailbox and netlog. Could do a complete copy of the db, but then everything will need to at least be encoded into something other than cleartext. Yes, I should probably do that anyway. It's a good thing that no one is actually waiting to use this, or paying for it, because it'd be very late, and extremely over budget.

So. All db fields should probably be encrypted.

Message relay: for asynchronous replication of the database. Write queries made locally will need to be logged (for backup purposes) and forwarded on to each application using the database. Idea here is to speed up each app by using the local databases instead of having a single remote database.

The query relay messages will need to have username/client information and possibly a TTL to allow for propagation of relayed messages amongst the various applications, but also prevent an application from processing a query relay message it sent to the network. (Network being used very loosely here.)

Don't really know about trying to implement a mailer-daemon/XMPP server/peer-to-peer overlay network kinda thing. Reading reading reading. Still think the bounce off an external server IP reporting thing would be simplest, and allows for direct connections. (Side note: could do a small HTTP server, then have each relay request a script which would queue the relayed message. Details, details.)

Client logon -> sends logon / pw to a local script (local db query) -> checks a remote script (with failover URLs for timeout factor) which will return HTTP_X_FORWARDED_FOR and REMOTE_ADDR.

The client will then parse the results of the script, and write username, fwd_for, and rem_addr to a database table. The remote script will also add said values to its db.

Direct client-to-client chat could then be performed by looking up a username in the table, and trying to connect to fwd_for and rem_addr at whatever port number gets implemented.

webweaving: a bit on XMPP

So it looks like the client can have an embedded XMPP server, and an account on said server. Which means that the client can then use its Jabber account to send and receive updates. All without having to configure Jabber accounts at a central location.

And yes, the IP address of the user will most likely change with every time they log on to the internet, but that can be worked around by doing an external IP check/report, then using the reported external IP. Add a "username" as the resource in node@domain/resource.

Or maybe have a remote table to resolve username to IP. Then have node@domain/resource look like username@username/resource.

"The domain identifier for every server or service that will
communicate over a network MAY be an IP address but SHOULD be a fully
qualified domain name (see [DNS])."

(http://www.ietf.org/rfc/rfc3920.txt)

webweaving: more nonsense for the client to do

Might change the way the pseudocryptography stuff works by actually generating sorta random keypairs. Store the private key only with the client, store the public keys in the db.

Since the db is going to be replicated on each client/bot/website, the public keys will be available for the encrypted message feature.

webweaving: More peer-to-peer messaging thoughts.

So there's ePost, which is built on FreePastry. Routes e-mail through POP3, SMTP, and IMAP proxies, and stores n extra copies of each mail across enough peers to keep it alive, even if most of the network fails horribly. Now, the actual embedded proxy server stuff isn't needed, but couldn't some of this functionality be carried over?

webweaving: Overengineering. Because my teeth hurt more than my hands and knees do.

(Obvious brainstorming disclaimer: probably not sensible, much less able to implement with current coding skillset.)

Been rethinking the bot/web bit. Why not have a client app as an additional means of interfacing with the data? Each user will need access to the database query logs for asynchronous replication. (So .htaccess or other password protection, or possibly a Jabber account, or some silly username/submitted password -> username/stored MD5 password check.)

Dynamic DNS - for client apps and the ingame bots. Could use the service at http://www.2mydns.com/domains.asp. Need to detect the public IP address of each client, then perform the update. Each client will also need to run some server code, if attempting the peer-to-peer networking thing. Should at the very least think of having static hostnames resolve to the bots, so that some round-robin functionality can take place, in case the website is not available.

Otherwise, can just get away with each client connecting through Jabber to the website (or similar idea) and not have to bother with the dynamic DNS / IP address / NAT traversal nonsense.

The bots will also need Jabber accounts/client functionality, as should the website. If a client sends an update to the website, the client script on the web server will then relay the message to each of the other clients, except for the originator of the message. Means changing the existing update relay code a bit, but that's something to do another day.

The ingame bots are for relaying messages to non-members, and for a bit o' redundancy. New message notification can take place through the ingame bot (if not logged in with the client app) or just through the client app.

All the actual database querying should take place on the client's local db, not any of the remote ones. This should speed up queries some, though if the db gets big, I'd imagine users not wanting a local copy.

(Side note: some really neat distributed systems stuff.)

Edit for stupid factor: (still in lotsa pain, so probably not making much sense) Can always just connect to the client apps via IP address instead of using a hostname. Durrrh.