Comment by miki123211
1 month ago
I wonder how they'll handle APNS, which will have to happen eventually.
Doing it costs money, and it's not a cost you can simply shift to the end user (because only the original app developer has the required Apple certificates, and you don't want every server owner to sign up for the Apple Developer program)
I'm assuming you're talking about Apple Push Notification Service.
Chatto so far commits to a fully fleshed out PWA experience. Push Notifications are delivered through Web Push (and Apple's Declarative Web Push additions). Web Push uses the browser vendors' own push gateways.
There are some missing bits currently in Chatto's multi-server story; when you add another server within the UI, its push notifications won't work because the other server can't make its service worker known to your device. One of the next versions of Chatto will improve this significantly, eg. with Chatto servers being able to act as push relays for others.
Eventually there's going to be mobile apps operated and provided by ChattoCorp, who will also set up and pay for the required push services.
Yeah, I'm working on a communications platform as a side-project, architecturally providing reliable communications is exceedingly difficult to self-host.
* Mobile calls are another form of push notification, Apple/iOS requires setting up APNS and Google/Android requires FCM, there is no self-hosted option for that at all and, for battery life reasons, no independent replacement is supported. Genuine ownership / independence from the main project requires, iirc, basically compiling from source to register different IDs against APNS/FCM.
* Trying to get into telephony, integrating with SIP is a huge pain. Nobody wants to deal with this.
* Nobody supports high availability for the underlying calls. None of the cloud L7 load balancers support media protocols - you're dropping down to L3 UDP load balancing. All of the available solutions (including LiveKit) depend on stateful services that, at best, place ceilings on call lifetimes (e.g. 5 hours) to allow for graceful draining, but "calls" in Discord-style settings where people connect to a room and stay connected will easily outlast those ceilings. Not supporting high-availability, IMO, is a huge ask for self-hosters - the price isn't in the maintenance window itself, but in deferring updates until the maintenance window, which can leave you vulnerable, particularly if you decide to leave the firewall open to ingress from 0.0.0.0/0 for ease of use. And of course, as a self-hoster, you rarely have a full follow-the-sun ops team, so either you schedule maintenance when everybody else is off (and you should be off too) or when everybody is on (and it's disruptive).
To be fair, I don't think Discord supports HA. As a pretty active user of voice calls on Discord, I've had plenty of cases where the entire channel drops for a second or two and reconnects, presumably to a different server.
If you do some kind of rolling upgrade, where each server has E.G. a lifetime of two weeks, with a 5 hour window where it doesn't accept new connections, I think you'll be fine.