Re: [Standards] On 'private' and 'no-copy'
On 10 October 2015 at 22:58, Matthew Wild wrote: > After various discussions, including here at the summit, I'm seeing a > rough consensus that the element in Carbons or the > ~equivalent hint in XEP-0334 cause more trouble than they > are worth. > > The only use-case I've been able to find is preventing OTR messages > from being received by clients that cannot decrypt them. It is > debateable whether receiving garbage is worse than not knowing that > someone is trying to contact you on another resource. > > FTR, I suggested a few use-cases (like IBB) which were all shot down for other reasons (like no ). So it really is only OTR, which itself misuses the body element. > As the elements are basically only a workaround for OTR, and OTR is a > hack, and OTR has its own methods to solve this issue, one could argue > that we shouldn't be using these elements. > > Does anyone have strong feelings about this? > > Regards, > Matthew > > PS. I don't want to get this discussion tangled up with the > advancement of Carbons, right now I'd rather just determine whether > these elements are useful or not. >
[Standards] On 'private' and 'no-copy'
After various discussions, including here at the summit, I'm seeing a rough consensus that the element in Carbons or the ~equivalent hint in XEP-0334 cause more trouble than they are worth. The only use-case I've been able to find is preventing OTR messages from being received by clients that cannot decrypt them. It is debateable whether receiving garbage is worse than not knowing that someone is trying to contact you on another resource. As the elements are basically only a workaround for OTR, and OTR is a hack, and OTR has its own methods to solve this issue, one could argue that we shouldn't be using these elements. Does anyone have strong feelings about this? Regards, Matthew PS. I don't want to get this discussion tangled up with the advancement of Carbons, right now I'd rather just determine whether these elements are useful or not.
Re: [Standards] 2016 Compliance Suites
On Sat, Oct 10, 2015 at 1:27 PM, Peter Saint-Andre - &yet wrote: > But nice UI indicators are what people care about. :-) That's fair. Maybe I should make a client that just always waits some random amount of time and then displays a green tick box (without actually doing anything on the backend). —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] 2016 Compliance Suites
On 10/10/15 11:11 AM, Sam Whited wrote: On Thu, Oct 8, 2015 at 10:32 AM, Curtis King wrote: On Oct 8, 2015, at 3:33 AM, Ralph Meijer wrote: I agree that the latter three examples are nice to have, but I don't agree that Carbons, Chat States or CSI are nice to haves at this point in time. Thats your point of view not mine nor our customers. That’s the problem with the XEP it has a very narrow scope, just like carbons. I think it makes sense to remove chat states and delivery receipts since they don't really do anything but give you a nice UI indicator. But nice UI indicators are what people care about. :-) Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] 2016 Compliance Suites
On Thu, Oct 8, 2015 at 10:32 AM, Curtis King wrote: > On Oct 8, 2015, at 3:33 AM, Ralph Meijer wrote: > > I agree that the latter three examples are nice to have, but I don't > agree that Carbons, Chat States or CSI are nice to haves at this point > in time. > > Thats your point of view not mine nor our customers. That’s the problem with > the XEP it has a very narrow scope, just like carbons. I think it makes sense to remove chat states and delivery receipts since they don't really do anything but give you a nice UI indicator. Carbons and CSI however have real benefits (in the form of making sure that a message gets delivered to the correct client(s), and making sure we're not eating battery on mobile devices). So I've left those in. The XSF may disagree, of course, but we'll see. —Sam
Re: [Standards] 2016 Compliance Suites
On Tue, Oct 6, 2015 at 8:23 AM, Christian Schudt wrote: > The same for PubSub, which is missing, although it seems to become more and > more important. Note that pubsub is covered by PEP. Is it necessary to list both? I wouldn't think so, but I have no strong feelings one way or the other. Might as well be explicit and list both I guess. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
