4 ms·

That makes more sense, thanks. Re sharing contacts by replacing User@Domain with numbers: Yes, this solves some of it because everyone agreed to use phone num

by cm3 10y ago

That makes more sense, thanks. Re sharing contacts by replacing User@Domain with numbers: Yes, this solves some of it because everyone agreed to use phone numbers, but phone numbers are a thing of the past and you don't always want to share your phone number just for messaging. Re notification overhead: If you have a system-wide notification display system, then of course the resources it requires are limited but you still have to have it running in the background in some form. Granted, it's probably easier to optimize it with everyone using the same notification system. This is just consolidation of a popular feature into system-provided functionality. Re lockin: But lockin still exists because you are the whim of centrally managed for-profit messaging backends, operated by entities whose intentions may not necessarily align with yours. I'm not aware of cross-app synchronization of messages and even less so a common message format (feature) set supported by all that provides a rich experience. I don't disagree with the cited shortcomings of XMPP, though you can always find a flaw in something which wasn't explicitly designed for the current use case, so ignoring that, the basic premise of XMPP is still sound and needed. Implementation details are something else, and honestly I don't agree that replacing XML with JSON (as in some of the proposals) gains anything in terms of efficiency, which it probably wasn't intended to anyway. My impression is that building a messaging system is simple enough that many variants pop pup, but almost all of them get interoperability, synchronization, mobility, and security wrong. It's unsurprising because the simplicity attracts implementers of all domain experience levels.

mike_hearn 10y ago
Android notifications do not require any app to be running in order for them to be displayed. lockin still exists because you are the whim of centrally managed for-profit messaging backends Given that 99.99% of people will never run their own servers, this is irrelevant: someone will be managing the infrastructure and those people will be motivated by profit. Welcome to capitalism: it works better than the alternatives despite its flaws. Things like WhatsApp or GChat do not simply replace XML with JSON. They tend to use binary protocols designed for low power consumption and ease of parsing. Arguably, if any protocol gets it wrong, it's XMPP ... I used to like it back when it was called Jabber, heck, I even hung out with a few Jabber developers back in the day. But Jabber's design goal was instant messaging and it's no longer useful for that. It just couldn't adapt to even quite small changes in circumstances.
- cm3 10y ago
  > Android notifications do not require any app to be running in order for them to be displayed. I didn't say there has to be. What I said is there's a single notification service which is reused by everyone. If you're saying that there's no daemon of sorts for notifications, then I'm curious where it's implemented. > Given 99.99% of people will never run their own servers, this is irrelevant It doesn't matter that someone won't run their own server. What matters is that you can, which means someone you know or trust can and give you access. These days it's much, much easier to run simple services like messaging if you consider the proliferation of remote accessible NAS boxes and such in households. Adding a messaging service to that is easy. Other than that you can use Sandstorm too if you don't want to operate a server. > Things like WhatsApp or GChat do not simply replace XML with JSON I'm sorry you thought I said WhatsApp or GChat use JSON. I mentioned it in reference to other messaging services.

by cm3 10y ago

mike_hearn 10y ago

Android notifications do not require any app to be running in order for them to be displayed. lockin still exists because you are the whim of centrally managed for-profit messaging backends Given that 99.99% of people will never run their own servers, this is irrelevant: someone will be managing the infrastructure and those people will be motivated by profit. Welcome to capitalism: it works better than the alternatives despite its flaws. Things like WhatsApp or GChat do not simply replace XML with JSON. They tend to use binary protocols designed for low power consumption and ease of parsing. Arguably, if any protocol gets it wrong, it's XMPP ... I used to like it back when it was called Jabber, heck, I even hung out with a few Jabber developers back in the day. But Jabber's design goal was instant messaging and it's no longer useful for that. It just couldn't adapt to even quite small changes in circumstances.

cm3 10y ago
> Android notifications do not require any app to be running in order for them to be displayed. I didn't say there has to be. What I said is there's a single notification service which is reused by everyone. If you're saying that there's no daemon of sorts for notifications, then I'm curious where it's implemented. > Given 99.99% of people will never run their own servers, this is irrelevant It doesn't matter that someone won't run their own server. What matters is that you can, which means someone you know or trust can and give you access. These days it's much, much easier to run simple services like messaging if you consider the proliferation of remote accessible NAS boxes and such in households. Adding a messaging service to that is easy. Other than that you can use Sandstorm too if you don't want to operate a server. > Things like WhatsApp or GChat do not simply replace XML with JSON I'm sorry you thought I said WhatsApp or GChat use JSON. I mentioned it in reference to other messaging services.