i’ve been working on the implementation of the chat system I talked about.
here’s the current spec document for requests that can be made to the user api. i’ve got tests and routing directives for three sections of that. (here’s how my implementation works: it processes the request – http verb, path, user auth – into an operation object, which it then sends to another actor (or actor system), which will do the database lookup and modification, and produce the response information, or raise an exception.)
as I’ve thought about this more, it’s become more clear to me that this can be extremely flexible. the crucial point will be designing the server-to-server api correctly – if I can pull that off, it’ll be capable of providing a single network with both large-scale public discussion servers and small private chat/info servers, with data from anywhere on the network available no matter where you connect (as long as your home server can be reached). hell, you could use a home server to set up topics that get fed by rss feed subscriptions and other info sources, and have those available on the go, encrypted and secured so other servers can’t read over your shoulder, while at the same time chatting in large public topics hosted by bigger servers. seamlessly.
plus, encrypted video chat on it still seems very doable.
raptros_ 