3 ms·
I'm not sure what you mean. The XMPP Standards Foundation still has a Board, as that's required by the foundation's bylaws. "Flag days" in a decentralized netw
by MattJ100 2y ago
I'm not sure what you mean. The XMPP Standards Foundation still has a Board, as that's required by the foundation's bylaws.
"Flag days" in a decentralized network have to be used with caution. Ask whether it's better to communicate without a specific feature, or whether it's better to split the network into fragments which are unable to communicate with each other. The former is almost always preferable, however we used the "flag day" approach for mandatory server-to-server TLS, for example (which actually isolated Google Talk from the main network).
As for acks, those were first defined in 2004, and have generally been implemented since the beginning in clients that need it (e.g. mobile clients, and every client since WiFi and laptops became ubiquitous).
I can think of a number of reasons that XMPP is often overlooked when it comes to modern IM, but this is a weirdly specific thing to pick out, especially when I can hardly remember a time it wasn't implemented everywhere.
- snvzz 2y ago>still has a Board Of course it does. A different one. >"Flag days" in a decentralized network have to be used with caution. Yet sometimes they are necessary, even if they annoy people. Core issues need to be fixed. >As for acks, those were first defined in 2004, and have generally been implemented since the beginning in clients that need it I am not talking about read receipts or the like. I am talking about TCP connections assumed reliable. Protocol's messages sent, and assumed received. Not clients, but more seriously server to server. This is why zombie presences were widespread. >I can think of a number of reasons that XMPP is often overlooked when it comes to modern IM There really is but one. It was infamous for being seriously unreliable, and as people moved to actually reliable IM systems (majorly proprietary), they never looked back.