Add CC support

[dovej]

CCs are way too commonly used for this to be overlooked. Perhaps the only remaining thing that has prevented me from becoming 100% independent of barnowl.

We need backend support to do this Right. Do we want to hack something together in the meantime, i.e. do it the way barnowl does it?

[cesium12]

You can probably just do space-separated in the recipient box. Question: do you also want to support non-CCed multi-recipient personals?

On Tuesday, July 8, 2014, Justin Dove notifications@github.com wrote:

CCs are way too commonly used for this to be overlooked. Perhaps the only remaining thing that has prevented me from becoming 100% independent of barnowl.

We need backend support to do this Right. Do we want to hack something together in the meantime, i.e. do it the way barnowl does it?

— Reply to this email directly or view it on GitHub https://github.com/roost-im/roost-client/issues/64.

~132.905~

[dovej]

Kata was talking about doing the fancy thing that gmail and others do where on space or comma it boxes each name, which can then be one-click removed. (Not necessary for initial support. Space or comma alone will do for now.)

We decided for now not to support non-CCed multi-recipient personals. It isn't used very often in barnowl IMO, and it can be mimicked by just copy and pasting the same message to multiple people. I think it'd just add confusion to the CC case which we really want to support, as it does in barnowl.

[davidben]

The server support wouldn't be too difficult, and I don't think you can really easily hack it in without it. I'd suggest just doing it right. I can coordinate with deploying it... (you'll want a migration script to update the conversation field on all the messages after the new algorithm is working). Without the server-side bits, you'll get extra outgoing messages on send and won't be able to filter right on receive.

[lightquake]

I think we should hack this in the frontend for now (and we can do something hacky to make filters work right), since I think enough people need CCs that we can't actually deploy to roost.mit.edu without this working.

[davidben]

How are you planning on getting send to work with a frontend-only hack? If the backend doesn't have support, every copy of the message you send will produce a separate outgoing message. Also filtering won't work. Note that CC's are /not/ a feature of the zephyr protocol. They're a convention. When BarnOwl sends a CC'd personal, it literally loops over every recipient and sends each a copy of the message.

This really isn't going to be a difficult backend change. I already intentionally designed the schema with this in mind; I just never got around to implementing the rest because I didn't want to parse CC lines, but you'll have to do that with a frontend hack too. Dunno when I'd have time for it, but it's really not difficult:

1. conversation field of a CC'd message contains NUL-delimited list of all non-sender participants of the conversation. Sorted alphabetically for canonicalization. Note this is completely compatible with the existing semantics of that field. And Kerberos uses C strings for everything, so there cannot be a Kerberos principal with embedded NULs.
2. When receiving a message, parse the CC line (you'll have to do this /anyway/). If there's a CC line, write out the conversation field using that rather than using the sender as-is.
3. Extend the /v1/zwrite entry point to allow setting a list of recipients. Send out a copy of the message to each person, but with only one outgoing message.
4. Optional and can be done later: rewrite the conversation line on all messages currently in the database for historical CCs.

That's it. Everything will work. Filtering on the conversation will DTRT. The front-end should then split the conversation field on NULs to get the full list of participants and then add some appropriate UI for sending CCs.

[lightquake]

Whoops, I forgot to mark 7acb793 as closing this. We have CC support in both the frontend and the backend, implemented basically like davidben said.