Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

need to catch up on this though. сб, 3 авг. 2019 г. в 21:04, Andrew Nenakhov : > вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer : > >> 1. Is this specification needed to fill gaps in the XMPP protocol >> stack or to clarify an existing protocol? >> > > Yes. > >

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

Telegram does. And at that point, why messing with XMPP at all? An FCM-only messenger can be coded in a week, it'll send and receive full message text via FCM, store messages on FCM cloud database and all will work admirably well. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <ht

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

he above. Of course, it is faster and simpler to do it this way! But at what cost? Agan, If we start developing the fastest solution, we'll eventually come up with some CA service that manages calls directly, fully bypassing XMPP. Is that what we want? -- Andrew Nenakhov CEO, redsolutio

Re: [Standards] Message Retractions

o hearing your thoughts on this. > > Regards > JC > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

ed separate (to self) and (to the > initator) messages. Instead, the will be carbon-copied to all > other resources, letting them know that one client accepted the call. Why is 353 not designed for carbons? is a and should be sent to other connected resources once the call is

Re: [Standards] Proposed XMPP Extension: Message Fastening

___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com>

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

пт, 6 сент. 2019 г. в 12:59, Georg Lukas : > > * Andrew Nenakhov [2019-09-05 09:45]: > > [..] So we have to > > operate fully without presence, thus, if a caller rejects a message at > > the exact moment we fetch an archive, we won't receive > > message i

Re: [Standards] Proposed XMPP Extension: Authorization Tokens

his", and would be > very grateful if you look at '399 and '397, as well as CLIENT-KEY and HT-* > over at the IETF, and if you'd like to take over '399 I'd appreciate it. We did look at these. 397 has a very different intent, and 399 suffers from key issues

Re: [Standards] Proposed XMPP Extension: Authorization Tokens

access stories', 'access personal data', etc). Issuing new tokens may be one of such scopes. Bottom end: if people here feel that we should explicitly specify that a tokenized session should be restricted from changing password - we can easily

Re: [Standards] Proposed XMPP Extension: Authorization Tokens

hough it'd need to be private of > course. You see, many things in messaging are 'trivial' and can be done rather easily. But for some reason no one bothered to do them in XMPP for decades.¯\_(ツ)_/¯ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com

Re: [Standards] Proposed XMPP Extension: Authorization Tokens

> tokens? We do not intend to support legacy clients without token support, it kinda kills the idea. However, we do plan to do PRs to select open-source clients to add this feature. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Stan

Re: [Standards] Message Retractions

to show errors, etc. (Also, MUCs are crap and must go down) -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Message Retractions

> > If anyone's really interested I can muster myself up and speed up > > translation to English. > I asked Google to translate it, but only half of the document got translated. We'll do our best to speed up the translation of o

Re: [Standards] Message Retractions

> can't be used on iOS. > > MAM catchup means fetching the messages you missed while you were offline. And if there were 1 messages? Quite plausible for a busy group chat. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com _

Re: [Standards] Resurrecting Reactions

ed and workload we might have a working prototype (client + server) to play with maybe in march, unless someone comes up with a better working solution. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> __

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

o: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> _

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

is sent-displayed, cause browsers require their own escaping. ср, 18 дек. 2019 г. в 20:41, Marvin W : > [inline] > > On 12/18/19 3:22 PM, Andrew Nenakhov wrote: > > In the end we have settled for counting characters of escaped string, so > > This sounds like a terrible idea. I

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

. I see you have a strong opinion on > the one side for some reason. > 394 does not even use same semantics that 372 use, so I would not even call them related. Sure, we could deprecate XEP-394, but I don't see a proper replacement > for it yet. I've sent our rather complete pro

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

пт, 20 дек. 2019 г. в 17:53, Dave Cridland : > > > On Fri, 20 Dec 2019 at 12:15, Andrew Nenakhov < > andrew.nenak...@redsolution.com> wrote: > >> You have sent a string '>>>>>', which was escaped to >> '>>>>>'

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

пт, 20 дек. 2019 г. в 19:25, Marvin W : > On 12/20/19 1:15 PM, Andrew Nenakhov wrote: > > You have sent a string '>>>>>', which was escaped to > > '>>>>>' before sending to the server. > > I have sent ">>>>&g

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

сб, 21 дек. 2019 г. в 14:53, Florian Schmaus : > On 21.12.19 10:50, Andrew Nenakhov wrote: > > > > > > пт, 20 дек. 2019 г. в 19:25, Marvin W > <mailto:x...@larma.de>>: > > > > On 12/20/19 1:15 PM, Andrew Nenakhov wrote: > > >

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

sentation of content. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

/#dt-cdsection>. > > I have a different reading of this. MUST be escaped using EITHER > OR character reference (WHEN it appears in the string ... ...) so OR branch is clearly used only for case listed in WHEN -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

r argument's sake, can you provide examples of XML processing libraries that work the way you describe and do not escape > all the time? We know none such, and we've tested dozens of them over the many years. Every single one always did the escaping. As I think it should, because c

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

irst thing we do differently. We'll probably change namespace for our references to not interfere with whatever you guys come up with. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___ Standa

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

*counting symbols differently. сб, 21 дек. 2019 г. в 17:22, Andrew Nenakhov < andrew.nenak...@redsolution.com>: > сб, 21 дек. 2019 г. в 17:12, Ralph Meijer : > >> So, having unescaped > is valid for case 2, and serializers may choose to >> do so. >> > >

Re: [Standards] Proposed XMPP Extension: Inbox

t this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______ > -- Andrew Ne

Re: [Standards] Feedback: XEP-0409: IM Routing-NG

bons instead of trying to refine its rules again and > again (and not being able to make it Draft). > -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___ Standards mailing list Info: https://mail.

Re: [Standards] Proposed XMPP Extension: Full Text Search in MAM

; Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Inbox

ср, 22 янв. 2020 г. в 16:44, Florian Schmaus : > > On 21.01.20 17:28, Andrew Nenakhov wrote: > > Notice: this is a rather early sketch of a copy of a technology that we > > already use to great results and have implemented in a open-source and > > available XMPP server and

Re: [Standards] Proposed XMPP Extension: Full Text Search in MAM

s could be sped up, so we don't deploy more instances of servers and clients that use search in 'ejabberd' way. Modifying ejabberd and our server and clients to this type of search looks rather trivial and can be done really fast. -- An

Re: [Standards] Proposed XMPP Extension: Inbox

l, and even Matrix client are all exempt from such problems. We, too, can either solve them or settle for mediocrity. I'd rather attempt to do the former. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Proposed XMPP Extension: Full Text Search in MAM

support, understand user's intent, etc. Google, Yandex, Bing, DDG, etc do not have separate input searchboxes for searchers with special terms and without them. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing lis

Re: [Standards] Call for Experience: XEP-0198: Stream Management

perfectly fine without XEP-0198. Android version will have it removed, too. Restoring a state > resumption of a stream. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/ma

Re: [Standards] Call for Experience: XEP-0198: Stream Management

t were sent to you during the > short period that you were disconnected? Through the message archive and with our device sync protocol. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabbe

Re: [Standards] Call for Experience: XEP-0198: Stream Management

ome merit to it with always connected modern mobile devices, however, personally, I am not ready to give up on green light bulbs on contacts just yet. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

I firmly believe that in 2020 the heavy lifting shold be done by servers. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

b clients. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

equal amount of traffic as with SM on reconnection, in best cases they result in smaller amounts of traffic. Mind you, I'm not advocating to drop SM, it's just our position that it is redundant for us. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com _

Re: [Standards] Proposed XMPP Extension: Reminders

d message), but in the end I rather preferred to keep it simple. Just build a bot that would send you reminders. No need to bloat the already huge number of extensions, -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards ma

Re: [Standards] Proposed XMPP Extension: Reminders

ence for whom? For developers of 50+ XMPP clients, who would have to consider support for yet another obscure XEP? Speaking of bots, clients can interact with them in a very convenient way using Data Forms (a long-neglected XEP-0004, which actually has a lot of potential for lots of various things

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

> Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

ср, 4 мар. 2020 г. в 11:10, Philipp Hörist : > > > > Am Di., 3. März 2020 um 21:19 Uhr schrieb Andrew Nenakhov > : >> >> >> I think this XEP should be obsoleted in favour of XEP-0333 Chat >> Markers, which does all that XEP-0184 does, plus something more. &g

Re: [Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers

; anyway) so we don't have an overlap in features and people stop claiming > that XEP-0184 might be obsoleted by XEP-0333. So you're ready to break a useful and working XEP just to stop me from (rightfully) claiming that XEP-0184 is obsolete? No wonder XMPP is such

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

idea to ensure delivery between clients is just plain wrong, because they are not designed to be constantly connected. Servers, on the other hands, ARE designed to be constantly connected, so it should be a server's job to keep track of such things (and we actually do exactly

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

пт, 6 мар. 2020 г. в 15:51, Georg Lukas : > > * Andrew Nenakhov [2020-03-06 11:10]: > > It is not possible to determine with Delivery Receipts either. If you > > were offline when they were sent, you will not receive them. > > If the recipient was offline when the mess

Re: [Standards] Council Minutes 2020-04-01

6:09 > 16:10 > 16:11 > 16:12 > 16:13 > 16:14 > 16:15 > 16:16 > 16:19 > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org &g

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

er clients that rely on web push notifications, they work mostly similar. Android can use this technique too, but on this platform it is not as vital as on iOS -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> _

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

e a test, I suggest you contact over email or XMPP (jid is same as email) and we'll provide you a window where everything will be in a working state. However, it will not be XEP-357 as it is written now but our necessary (even forced) improvements over it. -- Andrew Nenakhov

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

with these new pushes is this: if it can't be fetched from an archive, it's a problem. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

egular ways. It worked pretty well before Apple changed policies with background notifications, but it still works ok on Android. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jab

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

mehow cut them on the server, or the notification will be dropped by APNS. Also, OTR/OMEMO encrypted messages generally exceed the push notification limit by APNS (especially when encoded in base64), which makes this method even worse. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com

Re: [Standards] Proposed XMPP Extension: Quick Response

essage, because without magic there is no "reference" > from the response to the original message. > Can't we just use forms for this? -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___

Re: [Standards] Proposed XMPP Extension: Quick Response

entity to send such requests and review answers for them, so such feature will likely used only by bots. And for bot it is eaiser to process a form than a text message. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.red

Re: [Standards] Proposed XMPP Extension: Quick Response

ttons and options. It can be used for any kind of bots in a fairly straightforward way. I think that bloating a number of XEPs that are to be supported by various application developers is wrong way to go. In short, we are unlikely to support this. -- Andrew Nenakhov CEO, redsolution, OÜ https://re

Re: [Standards] Proposed XMPP Extension: Quick Response

evelopers to implement this. At least, unless people will start pointing fingers at Xabber saying, "ha-ha-ha, this obsolete client doesn't support this very essential and universally supported Quick Responces XEP, shame-shame-shame". -- Andrew Nenakhov CEO, redsolution, OÜ https://r

Re: [Standards] On Quick Responses

commands, it won't be based on messages received from an entity. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards

Re: [Standards] Proposed XMPP Extension: Quick Response

XEPs to matrix documentation, which would you chose as a 20 years old developers who wants to make a chat application? -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/lis

Re: [Standards] Sprint for Message Routing

t; .___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolut

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

вт, 28 апр. 2020 г. в 13:04, Daniel Gultsch : > Am Do., 29. Aug. 2019 um 11:26 Uhr schrieb Andrew Nenakhov > : > > >> We have implemented this specification on iOS client, and discovered > that it is unsuitable in real life scenarios. We have updated it with > addition

Re: [Standards] LAST CALL: XEP-0393 (Message Styling)

to implement. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] XEP-0333: meaning of 'acknowledged'

_ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com

Re: [Standards] XEP-0333: meaning of 'acknowledged'

чт, 21 мая 2020 г. в 22:06, Tedd Sterr : > > While scrolling could be taken as user interaction, I don't think that was > the intention. It is very clear that we should use 'displayed' for 'scrolling'. -- Andrew Nenakhov CEO, redso

Re: [Standards] Council Minutes 2020-05-27

d markup extension, because it is very consistent, works great with group chats, makes it easy to process markup, mentions, filter attached media, stickers, etc. ¯\_(ツ)_/¯ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mail

Re: [Standards] Very Simple Questions about Compliance Suites

abber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Form for Compliance Suites

d. This, again, is a bureaucracy for the sake of bureaucracy. The process can be precisely the same, you don't need to bloat the specs with entries that will be obsoleted in a year just because you need an archive or an orderly way to update information. -- Andrew Nenakho

Re: [Standards] Stanza ID of outgoing message

like this: > > | > | > | > > Thoughts? > > Holger > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _

Re: [Standards] Proposed XMPP Extension: Stickers

whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Andrew Nenakho

Re: [Standards] Proposed XMPP Extension: Stickers

Because you are happily oblivious to problems of clients on some platforms that have a very tiny window of operation before they have to break connection. ср, 18 нояб. 2020 г. в 23:10, Sam Whited : > > Why? > > On Wed, Nov 18, 2020, at 12:56, Andrew Nenakhov wrote: > > Using p

Re: [Standards] Proposed XMPP Extension: Stickers (use of PubSub)

чт, 19 нояб. 2020 г. в 17:45, Florian Zeitz : > > Am 19.11.20 um 11:11 schrieb Andrew Nenakhov: > > Because you are happily oblivious to problems of clients on some > > platforms that have a very tiny window of operation before they have > > to break connection. > &

Re: [Standards] UPDATED: XEP-0434 (Trust Messages (TM))

; time this email is sent. The XEP documents linked herein are up-to- > date. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _

Re: [Standards] Off-by-one error in XEP-372 "References"

_ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Off-by-one error in XEP-372 "References"

rrect. > Could you please share some of that feedback, Andrew? > > > Kind regards, > > Seve > https://delape.net > https://github.com/SeveFP > > > > On 04/12/2020 13:40 Andrew Nenakhov wrote: > > > > > > We're currently use it in all our cl

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

Upping a year-old email thread for Florian. ср, 18 дек. 2019 г. в 20:41, Marvin W : > > [inline] > > On 12/18/19 3:22 PM, Andrew Nenakhov wrote: > > In the end we have settled for counting characters of escaped string, so > > This sounds like a terrible idea. In encoded

Re: [Standards] Off-by-one error in XEP-372 "References"

ion never arises. > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, red

Re: [Standards] Off-by-one error in XEP-372 "References"

сб, 5 дек. 2020 г. в 05:12, Sam Whited : > > > > On Fri, Dec 4, 2020, at 23:34, Andrew Nenakhov wrote: > > 4. Start = first character (inclusive) and length = length of a > >substring. > > This is the same as "1. Start = first character (inclusive), end =

Re: [Standards] UPDATED: XEP-0434 (Trust Messages (TM))

I mean, what 'remaining authentications' are you referring to? Can you describe a scenario, like, Romeo with a smartphone and Juliet with desktop computer want to initiate an encrypted chat, what do they do? On Mon, Dec 7, 2020, 00:00 Melvin Keskin wrote: > Hello Andrew, > > thanks for your que

Re: [Standards] XMPP for true P2P (a.k.a. P2P-SIP, RELOAD, Jami)

-is-jami-truly-distributed/ > > Regards, > > Daniel > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _

Re: [Standards] XMPP for true P2P (a.k.a. P2P-SIP, RELOAD, Jami)

вс, 7 февр. 2021 г. в 12:45, Daniel Pocock : > Imagine a poster promoting this concept. A big headline, "SERVERLESS" > and a picture of the former US president. Former US president just needs his own server. -- Andrew Nenakhov CEO, redsolution, OÜ https:/

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

ess and may be stale at the > time this email is sent. The XEP documents linked herein are up-to- > date. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

uch proposals in other places, like a dedicated page on the > XSF website. > > If you have suggestions on how to improve our processes, we welcome your > constructive input. We then have clear ways to consider your > suggestions, including proposals to include cookie recipes. > >

Re: [Standards] Proposed XMPP Extension: Moved 2.0

What happens if a user has several connected clients that support this xep? On the broader subject, I think that any xep that is oriented at doing anything on clientside should have a mandatory section dealing with multi-device use cases. On Fri, 25 Jun 2021, 16:07 Jonas Schäfer, wrote: > The X

Re: [Standards] MAM Sync Strategies

etch the next page for as long as they > continue to scroll up. > > Thanks, > Sam > > -- > Sam Whited > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___

Re: [Standards] MAM Sync Strategies

to do requests to fetch at least 1 message for each contact in a roster. We had this functionality, worked, as expected, far from ideal, so we eventually scrapped it. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com>

Re: [Standards] MAM Sync Strategies

. Also, we have a similarly working demo of our group chat tech made out to work as a support chat widget: http://connector.chat/ it reloads almost instantly after each page reload (and even remembers the position if it was moved to another place), reloading everything from the archive. Yo

Re: [Standards] MAM Sync Strategies

пт, 27 авг. 2021 г. в 14:52, Holger Weiß : > * Andrew Nenakhov [2021-08-27 14:45]: > >our quick sync protocol that loads every first message from all chats, > > This sounds like a non-standard replacement for XEP-0430: Inbox? > Not quite. XEP-0430 is a (rather weak) imitati

Re: [Standards] MAM Sync Strategies

archive again is fast enough anyway, with any decent xmpp server. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards

Re: [Standards] MAM Sync Strategies

messages starting from, say, 20th? Those are mightily rabid users, I must say! -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com> ___ Standards mailing list Info: https://mail.jabber.org/mailman/li

Re: [Standards] MAM Sync Strategies

is incoming and stop ringing immediately after the call is picked or reclined on one device, or when it is cancelled by the caller. (further complicated if caller sends something) -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <htt

Re: [Standards] XEP-0353: Rework whole spec, namespace bump

This made me smile. Thilo on August 27, after being told about issues in current XEPs: > I'll show you how to make VoIP calls work on iOS with given XEPs and without inventing new ones as soon as I come along implementing the new WebRTC based VoIP XEPs. Thilo on December 8: > Rework whole spec.

Re: [Standards] Feedback on the proposed CoC

1. From what I've seen, CoCs are used so silence or scare into silence people with differing political opinions (so much for tolerance). The language of this CoC, too, is too broad and allows for such misuse. 2. XEPs are not the place for such documents. If XSF wants to have a code of conduct, it

Re: [Standards] Feedback on the proposed CoC

> > > On 04.02.22 11:20, Andrew Nenakhov wrote: > > 1. From what I've seen, CoCs are used so silence or scare into silence > people with differing political opinions (so much for tolerance). The > language of this CoC, too, is too broad and allows for such misuse. &g

Re: [Standards] Proposed XMPP Extension: Ephemeral Messages

://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mai

[Standards] Re: Chat Markers and Read Status

ients to be more interested in the raw > count returned by RSM than the individual messages. > > Any thought ? > > Regards, > Simon > ___ > Standards mailing list -- standards@xmpp.org > Info: Unsubscribe: %(real_name)s-unsubscribe@%(

[Standards] Re: LAST CALL: XEP-0333 (Displayed Markers (was: Chat Markers))

We use Chat Markers extensively. For what it's worth, I think that it was a bad idea to remove to not replicate XEP-0184, because reading one spec is better for developers than reading two, and I'd rather revert changes back to 0.4 and deprecated 0184 instead. Also, Displayed Markers (was: Chat M

[Standards] Re: UPDATED: XEP-0333 (Displayed Markers (was: Chat Markers))

As I said earlier, some day down the road can actually be useful: > But I could see this feature useful for something like voice/video messages to indicate that it has been played by the recipient. At least, Telegram does have such feature (not in group chats though, there it makes no sense and w

[Standards] Re: UPDATED: XEP-0333 (Displayed Markers (was: Chat Markers))

Well, on the other hand, since the only scenario I can imagine using in the wild has significantly different semantics from readdisplayed markers, I think that this is not really necessary in this XEP. On Tue, 26 Mar 2024 at 17:34, Daniel Gultsch wrote: > On Tue, Mar 26, 2024 at 1:11 PM Dave Cr

[Standards] Re: Send-only role

Early on in our implementation of our group chat protocol, we had a separate 'send messages' and 'receive messages' rights, but then decided that no chat entity would be necessary that would not have a capability to receive all messages and we opted out of it in implementation. The case presented b

[Standards] Re: XEP-0402: PEP Native bookmarks and defintion of a groupchat chatroom (was: XEP proposal: filtering chat notifications)

On Wed, 29 May 2024 at 19:41, Marvin W wrote: > On Wed, 2024-05-29 at 08:57 -0500, Stephen Paul Weber wrote: > > > > I disagree. I think it is a chatroom. > > A user is not a chatroom. A chatroom is something where users join and > leave and send messages to that are received by other currently j

[Standards] Re: Encrypted peer-to-peer XML channel

We're not currently doing it but considering to do in the future. Very much likely we'll just do an upload of an encrypted archive via cloud storage. This way it can be interoperable with the likes of Dropbox / gdrive / whatever. On Tue, Jul 16, 2024, 00:51 Tim Henkes wrote: > Hi folks, > > > I'

  1   2   >