chatwoot VS Gotify

Compare chatwoot vs Gotify and see what are their differences.

Our great sponsors
  • OPS - Build and Run Open Source Unikernels
  • Scout APM - Less time debugging, more time building
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
chatwoot Gotify
15 30
11,863 6,953
3.8% 2.0%
9.8 6.2
about 14 hours ago 8 days ago
Ruby Go
GNU General Public License v3.0 or later GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

chatwoot

Posts with mentions or reviews of chatwoot. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-08-21.

Gotify

Posts with mentions or reviews of Gotify. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-11.
  • ⟳ 1 apps added, 64 updated at f-droid.org
    35 projects | reddit.com/r/FDroidUpdates | 11 Jan 2022
    Gotify (version 2.3.1): A client for receiving push notifications
  • Show HN: A tool to send push notifications to your phone, written in Go
    16 projects | news.ycombinator.com | 28 Dec 2021
    Hello Philipp, what benefits do you think make the app shine against something like Gotify? It looks like you have integrated with firebase. What else should I be looking for? The firebase path looks interesting for my 'toy' messages so save some battery life.

    https://gotify.net/

  • Simple Raspberry Pi Powered SMS Gateway
    5 projects | news.ycombinator.com | 5 Dec 2021
    If you're on Android, there's Gotify [1]. You can self-host the server and install the app on either the Play Store, F-Droid, or just by downloading the APK.

    [1]: https://gotify.net/

  • Sending mobile push notifications to yourself
    2 projects | news.ycombinator.com | 25 Nov 2021
  • a way to send short messages between devices?
    6 projects | reddit.com/r/selfhosted | 24 Nov 2021
    Sounds like a good use for gotify https://github.com/gotify/server
  • Google Play permitting alternative billing systems for users in South Korea
    2 projects | news.ycombinator.com | 19 Nov 2021
    Restricting background apps by default is probably good. But Google didn't have to lock users in to their service to provide a good push notification system on Android.

    The correct solution here would have been a system-level, open source, provider-agnostic push notification API built into AOSP. The Web Push API is a great example of how a push API can be provider-agnostic: https://developer.mozilla.org/en-US/docs/Web/API/Push_API. It makes sense that push notifications should be consolidated to one provider -- this way, your device only needs to maintain one 24/7 connection to a server which it receives all notifications from all apps through, rather than having each app run its own notification service in the background, killing your data and battery life. Push services, like Google's, work by providing an HTTP endpoint to apps that they deliver to their backend and can use to send notifications.

    The Web Push API also works by allowing a web page to request an HTTP endpoint to use for sending push notifications, but the returned endpoint can be for any provider. If you use Firefox, the domain will be mozilla.org; on Chrome, it's google.com. But each provider's endpoint uses the same standardized API, so the backend doesn't have to care what the URL is. And this isn't a security risk either, because everything sent through the push service is encrypted.

    This could have been done for Android, but that would have given Google much less control over the platform, so they decided to do it in a monopolistic way. This is one of the many ways Google aims to maintain their monopolistic control over "open source" Android. Another example is SafetyNet hardware-backed attestation.

    Projects like GrapheneOS are really interesting because they are finally providing a real, secure, de-Googled OS option, with excellent app compatibility due to sandboxed Play Services (which allows you to run Play Services without giving it root access to your device). But will we ever be able to fully decouple Google from Android? I'm not sure. I expect most users of custom ROMs to continue installing Play Services on top of them for a long time, if they want something as basic as push notifications to work.

    By the way, while I personally have qualms with Google, I believe users should have the choice to use Google apps, if they are comfortable with the inherit privacy risks. This is how the GrapheneOS developers approach it, as well. [1] My problem with Android is that it was not built to function without Play Services. Community projects that allow it to do so will always be a cat-and-mouse game with Google. I think sandboxed Play Services is the most sane solution to the problem of Play dependencies the community has come up with so far, but I think if we want real change to happen, we need to target app developers. Each developer has the choice of whether to include Google or not within their app. We just need to convince them that they don't need Google.

    Google owns `developers.android.com` and points developers towards using Play Services APIs wherever possible. Perhaps the community should create their own open-source alternatives to the most commonly used APIs (e.g. push notifications) and developer documentation that provides instructions on how to switch from Google (ideally making the transition as easy as possible by emulating the Google API syntax). It would probably be possible to offer an installable platform-agnostic push notification API that developers can use. Providers could be installed as separate apps. Google could be one such provider. Perhaps we could implement a Web Push compatible API, and reverse engineer Chrome's Firebase integration to implement it as an option from the get-go, hoping other providers show up over time. We could perhaps allow users to self-host their push service as well. Modify Gotify (https://gotify.net/), an open source self-hosted push server, to accept push notifications in the Web Push format.

    In the hacker circles it seems there's two groups of people: those who think Android is a lost cause because it will always be controlled by Google, and think Linux phones are the only real alternative, and those who believe we can actually "steal" Android back from Google and make it into a true open source project. I fall into the latter, but I think a lot more work still needs to be done.

    [1] https://grapheneos.org/features#features

    > We aren't against users using Google services but it doesn't belong integrated into the OS in an invasive way. GrapheneOS won't take the shortcut of simply bundling a very incomplete and poorly secured third party reimplementation of Google services into the OS. That wouldn't ever be something users could rely upon. It will also always be chasing a moving target while offering poorer security than the real thing if the focus is on simply getting things working without great care for doing it robustly and securely.

  • Überleben mit einem Handy ohne Google oder Apple
    1 project | reddit.com/r/de | 5 Nov 2021
  • A simple server for sending and receiving messages in real-time per WebSocket.
    1 project | reddit.com/r/golang | 16 Oct 2021
    1 project | reddit.com/r/selfhosted | 16 Oct 2021
  • Gotify/server: A simple server for sending and receiving messages in real-time
    4 projects | news.ycombinator.com | 16 Oct 2021

What are some alternatives?

When comparing chatwoot and Gotify you can also consider the following projects:

PushBits - A simple server for push notifications via Matrix (and a minimalistic alternative to Pushover and Gotify with a strong focus on security) 🚀📯

element-android - A glossy Matrix collaboration client for Android.

Papercups - Open-source live customer chat

docker-homeassistant

LeapChat - Ephemeral, encrypted, in-browser chat rooms

Tinode - Instant messaging platform. Backend in Go. Clients: Swift iOS, Java Android, JS webapp, scriptable command line; chatbots

redpanda - Redpanda is the real-time engine for modern apps. Kafka API Compatible; 10x faster 🚀 See more at vectorized.io/redpanda

Darkwire.io - End-to-end encrypted instant web chat

jest - Delightful JavaScript Testing.

Nginx Proxy Manager - Docker container for managing Nginx proxy hosts with a simple, powerful interface