bkad / prat Goto Github PK

currently using the user's name, which can be the same for different emails.

Youtube, vimeo, etc.

I started doing this but then realized it's a pain in the ass because of how callbacks work with sundown.

Here's a regex for youtube.com links to get started:

r"(https?://)?(www\.)?youtube\.com/watch\?\w*v=(?P<id>[0-9A-Za-z+)\w*"

expose a big ass trash can glyph when dragging channels to allow them to delete them

Whenever a new message comes in on a channel you're not active in, do something like accent the border of that channel to quietly inform the user that there are new messages to be read

Thanks to @tobert for pointing this out. It would be stupid easy to support conference calls a la Campfire using Tropo:

https://www.tropo.com/docs/scripting/creating_conference_call.htm

http://packages.python.org/Flask-Login

Required to support multiple authentication mechanisms e.g issue #51

Right now if you navigate to a different page and then navigate back, you'll get the view of the page when it loaded. subsequent messages will be appended, so you end up with a big gap of missing messages. You can reload the page to fix this.

We should use the HTML5 history API to fix this experience.

I see two issues that both expose you to some kind of length extension attacks. @mdietz can tell you more :)

• No delimiter between the components that comprise the canonical string
• SHA256 instead of HMAC-SHA256

Lots of people get this wrong, but we should fix at some point.

I think a good example is AWS signature generation:

http://docs.amazonwebservices.com/amazonglacier/latest/dev/amazon-glacier-signing-requests.html#example-signature-calculation

There are really two parts to this, the actual design/implementation of the reconnection and the UI to let the user know what's happening.

Hit 'Preview' to see a Markdown-ified preview of your next message

refactor this into a function (something like get_db) to make it easy to refactor if we switch datastores

like this

going to get pretty messy if we continue having the rendering logic both client and server side

Necessary for using livecss in dev.

This project needs tests. Right now, they would be valuable for the webserver code. The client code will likely become complex enough that you'll want coffeescript tests as well.

It sucks to work on a project when it's complex enough that you have no way of knowing that you're not breaking stuff.

detect if cursor is at the beginning of the message input. pressing up and down goes through your message history.

OAuth2 is going to be better supported and give us finer grained control over the scopes we're asking for (email and profile scopes).

Accountchooser.com should give us a wrapper that will allow users to authenticate with the big 3-5 identity providers (Google, Facebook, Hotmail, Twitter, Yahoo). See: https://www.accountchooser.com/learnmore.html

Right now, if I'm scrolled to the bottom and I make the window smaller, I'll be scrolled a little bit up. We should make the bottom "sticky"; i.e. if we're in "at the bottom" mode we should stay scrolled to the bottom if we resize the window.

Mozilla's persona project allows for federated login support using an email address as the identifier for a user (and the identity assertion is backed by some clever public key crypto so this should be more secure than any kind of bearer token based federated login system).

http://www.mozilla.org/en-US/persona/

Make the timestamps contextual rather than absolute, aka:

• A moment ago
• X minutes ago
• X hours ago

Finally:

• DateTime

Allow the user to toggle between using Enter and Shift+Enter to send a message. Expose a little toggleable button to switch between the states.

Right now whenever you refresh, you leave behind websocket file descriptors in a CLOSE_WAIT state. You hit the file descriptor cap for a process pretty quickly, and the process crashes in a blazing fire.

after X (say 5 for now) minutes of no new messages, the next message should create a new message container regardless of whether the author was the same.

This is important if we want to use Prat for any kind of corporate use. That way we can use it without VPN.

We need something that isn't the most annoying sound ever.

Remember the open/close state of the left and right panels (channels/users). Use cookies.

There is a weird bug that occurs if you switch channels. After switching, it will be at the bottom of the screen, but if you use the scroll wheel at all you'll suddenly jump to the top.

Consider using zeptojs as a drop-in replacement for jquery.

In principle it seems nice because the library is smaller and drops support for older browsers.

create a /rooms/:name route
when a user navigates to it, it adds it to the list of the user's rooms and sets it as the current room

mainstream gevent-zeromq has a green poller implementation now so the fork is no longer necessary

Once the socket disconnects and opens up again, have it queue up incoming messages while you fetch all the messages you missed. Then dump the missed messages + the queued messages into the DOM.

Not quite released yet, but soon the functionality of gevent_zeromq will be merged into pyzmq

Where username is the everything before the @ in the user's email address.

might have to fork misaka/sundown to do this

A chat is considered to be directed towards a person when a message includes @username where username is the everything before the @ in the user's email address.

Every minute (when timestamps refresh) the padding between the messages-container and the input-container collapses. It reappears if you open up chrome inspector.

Turn #foo into a channel link. Clicking it will add it to your list of channels if it isn't already in your channel list, then sets it as your current channel.

Currently we're creating a popup window when a user opens the login dialog. Setup Oauth2 / OpenID redirect URIs to fix this,

Probably require user preferences in general.

To determine whether a user is online, we track all their open clients in a redis sets (under key: user-clients:[email protected], adding and removing clients as they connect/disconnect.

It's possible, however, for a client to connect, and add their key to the open clients set, and then fail (due to a server shutting down, or some other error). In order to evict these orphaned client ids, one could run a separate process which sends hooks into the pub/sub system, sends pings to clients, who send back pongs which include their client ids. The process could then determine which keys are valid in the redis client pool and evict those which aren't.

Could be a nice chance to write some gevent code. Could have a master thread tracking all open clients, which spawns randomly offset X seconds from eachother and reaps a thread when the user the thread is tracking is has no open clients. Each child thread polls its open client pool every Y, sends pings, waits Z seconds, then evicts all client_ids which didnt send a pong.

We'll need a keyboard shortcut help dialog of some kind as well.

Some initial ideas: (ctrl on linux/windows, cmd on mac)

• j/k to scroll the message pane up and down
• ctrl-u/d to scroll up and down by half a page
• G to scroll to the bottom
• ctrl-n/p to switch next/previous channel
• ? open keyboard shortcut help
• enter to focus the text box
• Typing anything that isn't a shortcut on the page also focuses the text box?