Notes from the Project Waverly meeting on July 3, 2011 The background is that we've looked at some existing software: * Google Wave -- why that failed, published protocol, alogorithm is totally XML based, but not everything works well like editing images * Etherpad -- under-maintained but open source, we have it deployed, but not really maintainable, only a web client; unsatisfied with poorly organized code, not as extensible as would be nice to add access control or other nice things, auth support is you buy an account from them, emacs plugin would require rev enging the web client and having emacs pretend to be a web client Other things in the space of collaborative text editing: * Gobby / Infinote -- free software, not widely used, ubuntu used to use it, should install and test it/use it; infinote is the protocol and it uses a single master design, emacs plugin (worked poorly 8 months ago) We could copy the etherpad UI design because it is reasonable. * SubEthaEdit -- mac only, but the sharing protocol isn't open source, however, it works well, hard-coded to be a particular client * collabedit -- seems to work, but no source or no anything else What do we want to see in this project? How ambitious? * Plugin to editors so it's not like SubEthaedit, emacs, vi/vim, etc. Restrict to this for now. * not chained to a web client, http as a transport layer is probably not a huge problem * Edit images? Do we want the protocol to be extensible to both? They seem like different topics. Text that can include images would be nice. Editing the image element would be nice to support. * Rich text support? If you want a web client, yes, emacs client could format out the formatting. People who are hacking on it are likely to be using emacs or vi/vim so good to cater to those who it helps most. People will be using the web client, though, too, especially if it extends past SIPB. * want a client to do git to waverly * client server architecture? decentralized? Gobby forces server/client. Decentralized allows for people on the same subnet to be faster/people in CA to be happier. Skype super nodes to replay instead of someone's laptop being the server. If I leave, not everything should fall off the face of the Earth. Client server protocol --> decentralized server? How does this affect security if we add decentralized? How does decentralized work with the web client? Connect to a central public server. Javascript to decrypt. Decentralized helps if many people are not on the web server and the desktop client, or web client can interact with the desktop client spawning a web server. Web client does http auth security, desktop client does something else? * Crypto -- secure editing, access control or encrypted Server takes care of security for you with web client? Need to run crypto with the desktop client. Is this protocol split a good idea? Communication the same, authentication different. * HTML for rich text or .rtf? Probably html. Can't you just render it? One person bolds, another person deletes... removes a closed tag. Balance of tags? * Zephyr integration? --> API for plugins * syntax highlighting * How do we plan to keep track or revision? Lamport clocks/vector clocks? You should not share clocks across documents DP2s from 2010 solving this? granularity of revision: per keystroke is good/as atomic as possible is good. resolve by user id not just time stamps to get consistency and elegance instead of just consistency want atomic move, add, delete. atomic find and replace would be nice. possibly regexes. format. characters never get deleted they just get marked as invisible how to insert: between two characters, offset, cursor? locks? Social locks as another formatting piece. Global counter would be malicious elsewhere Research on malicious participants Files: list open/create/read/write close delete rename mkdir Update: insert delete move region find/replace regexes? format (B I U etc) social lock chat send callbacks api file changed, message, directory changed First release: * Protocol that doesn't support rich text or images at first, quick web client. Next release, plugin support for emacs/etc. Keep in mind how to add security later * Should be easy to throw together a web client, also then it's uniform at first. * Decentralize after the first release of the protocol. * Two different conflict resolution schemes for plaintext and rich text? First round needs: * web client -- afarrell, cesium * server/backend/protocol/design docs -- lizdenys is PM'ing this, geofft, maria89 * API (does it need to be different from protocol?) Also someone should: Look through gobby, can we do something infinote compatible? --> afarrell Things to do: * figure out what existing software is there and whether we like it * figure out what's in scope and come up with a schedule --> decide short term and long term goals what do we need to make a first public release? what should we keep in mind --> use crypto in it because crypto rulez find what crypto we want to use (DTLS?) figure out a reasonable authentication system (PKI? certs? our own accounts? Facebook Connect?) figure out a reasonable authorization system / ACLs * read some papers? * figure out what people want to actually work on * figure out what people would like to see happen Academic background: * operational transforms * decentralized? decentralizable? centralized? (pls no) I'm not convinced decentralized is possible, or a good idea for revision 1, but I want decentralizable * stuff about decentralized: Paxos and friends -- I would like to not implement paxos pls What do we need for a first release? - define what we want to see long-term - split that into unimportant, important to keep in mind but not code, medium-term, and short-term What sort of content do we want? - plain English text - plain text with some special format -- custom merge drivers? - rich text (what format?) - lilypond support! - hooks into other editors? - customizable formats - multi-page documents like slideshows?