id

40

publisher

goffi@goffi.org/d08fc2c8-30c5-4081-bff7-2f0f733436e8

title
Message addressing, visibility and sharing
author
Adrien
created
25/06/2013, 11:28
updated
29/11/2013, 09:05
labels
Libervia
type
bug
status
closed
priority
normal
milestone
0.7
severity
normal
body
I was writing some implementation proposals and realized I was actually describing the way email addressing is working... it is actually a bit more complex because we do the difference between private messages and micro-blog post, but the idea is more or less the same. I may have been inspired too much, as 1. the goal is not to make a webmail but a new communication tool, with new technologies... interface and usability can be new too. Also 2. do we want to complete the existing email system or include it (do we push the people to use SàT for all and not use their email anymore?)? Anyway, here are the ideas that should be discussed: - send a micro-blog post to several groups - send a private message to several contacts : this is not really needed as you can create a new group instead... but sometimes that could be preferable if you don't want to use that group again. Open question : should the message be delivered to the recipients as a private message or as a micro-blog post? - mix groups and contacts as the recipients of a message : same open question, will it be delivered to the contacts as a micro-blog post or a private message ? To make it available, the way addressing "prefixes" are handled need to be improved a bit. For example "@test@friend:" or "@test @friend:" is currently sending the message to PUBLIC. In addition: see bug #32: not only forbid ":" in group names but also "@". If the privates messages recipients can be defined from the text input, we have a problem with the @ character which is both a separator and part of the recipient JID --> change the separator to another character?! - allow a recipient to see who are the other recipients... actually, I think we should copy the way email addressing is working we need a system like BCC (at least), and eventually also a CC... especially if SàT aims to be used by companies for business purposes, it is mandatory to have a distinction between A and CC. People need to know if something is required from them or if it's just a "FYI". Putting all that together, I wonder how we could manage several recipients and TO/CC/BCC with that only prefix "@...:"... even if it's technically possible we need an easy way for the users. I would go for a button left to the text input, when you click it appears a popup with the three lines TO/CC/BCC, it works with auto-completion of course :) Validating the popup dialog, should the one-lined syntax be written in the text input? That may take all the space... Open question. - we also need a "Forward" button. Public messages can be forwarded to anybody. For restricted visibility messages, this is open question : the user always have the possibility to copy/paste the text anyway, but maybe it's better to restrict sharing a non public message - or ask the initial author to confirm the share. This sharing system can probably be used also for the events invitation system. - last but not least... should we stay with "chat-style" private message and micro-blogging or go further and do some normal email and blogging? In that case we also need a title bar... so to say, have a message dialog with TO/CC/BCC, title and body as any email redaction tool. PS : it is obvious that people are bored with filling recipients of each message... this is one of the biggest reason why social network like Facebook are so popular. I can imagine we could also propose two way for addressing messages : this TO/CC/BCC from the email and another system with no recipient list but only a visibility parameter (a bit like the 5 visibility levels of Movim, easily identifiable with their colors).
comments_uri
xmpp:pubsub.goffi.org?;node=urn%3Axmpp%3Amicroblog%3A0%3Acomments%2Forg.salut-a-toi.tickets%3A0_40
These requests are partially implemented by the current microblog system and soon with the address extension (XEP-0033) which is under development. The forwarding functionnality will be implemented with XEP-0297.

You are not logged. You need to log in to comment.