redesigning chatless

towards a simpler, more implementable chatless

chatless has the goal of being a message board system that is fast enough and flexible enough that it can serve where both instant messaging and twitter have previously.

why does it need re-designing?

the original chatless api model was too complex. too many things carried information, too many things had request endpoints. this was bad and stupid.

what now?

a simpler model.

• here's the big secret: the only thing that'll carry information is topics. users won't have their own information, they'll just have their about topic, which is one of the topics associated with them.
• the goal of making the api generally human readable remains, though.

model

what is a coordinate

the coordinate of an object contains all the ids needed to obtain that object directly.

• for a server: serverId
• for a user: serverId, userId
• for a topic: serverId, userId, topicId
• for a message: serverId, userId, topicId, messageId

server

for now, a server just has an id. later this will be important. i haven't figured this out enough, though.

user

model:

• server: the id of the server this user is from
• id: an id unique on server
• about: a topic id (bare) - this is the reference to what might be called the canonical topic for this user. the title of the canonical topic is the default nickname of the user, the messages are whatever the user chooses to publish, etc.
• pull: a set of topics the user is interested in receiving messages from

associated:

• keys: public keys (with related information) for the user. see auth.
• topics: the topics the user has created
• messages: (nonpublic) the queue of messages for the user to read. size limited by the server. it contains message coordinates.
• requests: hmmm....

topic

model:

• server, user, id: the coordinate of the topic
• banner: some string
• about: some json
• mode: a bunch of flags controlling who can do what

associated:

• objects
• files
• members: user coordinate and member mode pair. the member mode object controls what that member can do.
• messages

objects

resources

members

messages

requests

api

http

auth

the plan on auth is

• a user has a set of published public keys.

currently authed user

• /me

some user

• /user/{id}
• /user/{id}/about - a topic
• /user/{id}/topic - list topic ids
• /user/{id}/topic/{id} - a topic

remote server

• /server/(serverid)/(api)