Ursprünglich veröffentlicht: https://www.kuketz-blog.de/messenger-wechsel-von-signal-zu-molly-unifiedpush-mollysocket-ntfy/
Der Messenger Signal kann auf Android-Geräten auch ohne die Nutzung der Google Play Services bzw. Firebase Cloud Messaging (FCM) betrieben werden. Damit ist der Messenger auch für diejenigen nutzbar, die bewusst auf die Datensammlung von Google auf ihrem Smartphone verzichten möchten. Der »Fallback« auf WebSockets funktioniert zwar, führt aber bei einigen Nutzern zu teilweise erheblichen Akkuproblemen, insbesondere im Mobilfunknetz. Seit Jahren gelingt es der Signal-Foundation leider nicht, die Ursache des Problems zu identifizieren. Eine Alternative zu Signal ist der Fork Molly, der in drei verschiedenen Varianten angeboten wird. Die Version Molly-UP verzichtet vollständig auf proprietäre Komponenten und kann Push-Nachrichten wahlweise über WebSockets…
Da werden dazwischen wesentliche Bestandteile “verschluckt".
Über die gleiche Lücke bin ich auch gestolpert.
Die naheliegende Vermutung ist, dass dort die Links zu ntfy und zu Molly-UP stehen sollten; das sind ja die beiden Apps, die benötigt werden.
https://f-droid.org/de/packages/io.heckel.ntfy/
https://github.com/mollyim/mollyim-android-unifiedpush (dafür gibt’s ein F-Droid Repository)
Benutze das setup mit molly-up, Unified push und ntfy schon länger und es funktioniert echt super. Als Server benutze ich auch adminforce. Das einzige was bei mir nicht geht, Standort teilen. Da zeigt er keine Karte an und die APP hängt sich auf. Weiß nicht ob noch jemand das Problem hat
Also vermuten tu ich nichts. Was dort eigentlich stehen müsste ist mir bewusst 
Das kann man schließlich auf dem Blog lesen 
Mir geht es darum das beim kopieren (was soweit ich meine mich zu erinnern automatisiert von Blog zu Forum passiert) Teile verschluckt werden. Ich wollte lediglich dazu beitragen den Automatisierungsprozess zu verbessern
Ja hier… habe auch das Problem, daß ich beim „Standort teilen“ keine Kartendarstellung habe, obwohl die Straßennamen angezeigt werden… das Teilen selbst mündet genau wie bei dir, Dauerschleife und App muss beendet werden 
Schande … genau das hatte ich natürlich nicht gemacht.
Sehr hilfreicher Ratgeber. Ich wünschte nur, es gäbe noch mehr UnifiedPush-Apps! Die einzigen, die ich benutzen würde, sind Molly und Element. Und bei Element sind mir die Benachrichtigungen eigentlich egal. Und wenn Molly die einzige App ist, für die ich UnifiedPush benutze, dann kann ich es ja gleich sein lassen (Akkuverbrauch ist ja dann identisch → nämlich eine Websocket-Verbindung, ob jetzt unmittelbar von Molly/Signal oder mittelbar durch ntfy).
Nein, der Akkuverbrauch ist nicht identisch. Die WebSocket-Implementierung bei ntfy benötigt - zumindest bei mir - weniger Akku.
@Figorino Im Matrix-Raum „Molly“ gibt es mindestens eine weitere Person, die das gleiche Problem hat…
Zu den „Bedenken“ hätte ich zwei Nachfragen:
-
Erfährt die zusätzliche Infrastruktur (MollySocket, ntfy) bzgl. meiner Kommunikation ausschließlich von der Tatsache, dass es für mich eine neue Nachricht bei Signal abzuholen gibt?
- Anders gesagt - ist es korrekt, dass es im Wesentlichen so abläuft:
Signal schickt Info:Es gibt eine Nachricht für ForestyDawn abzuholen→ MollySocket → ntfy → mein Gerät => Gerät holt Nachricht bei Signal ab? - Die Formulierung im Blogbeitrag dazu ist m.E. etwas unklar:
Die Informationen, die dabei anfallen, sind einmal die Push-Benachrichtigung von MollySocket und die IP-Adresse.Was beinhaltet „die Push-Benachrichtigung“?
- Anders gesagt - ist es korrekt, dass es im Wesentlichen so abläuft:
-
Ob ich adminforge vertraue, ist mein Problem, klar. Ich habe hier und generell im Kontext Android-Datenschutz / „Self“-Hosting / etc. in letzter Zeit wiederholt von dem Anbieter gehört. Gibt es gute Gründe dafür, dass man ihm hier scheinbar generell vertraut und ihn gerne empfiehlt?
Hallo ForestyDawn,
zu deiner Frage 1: es werden genau die Schritte durchgeführt, wie du im Unterpunkt 1. benennst, genauere Infos mit Flussschema gibt dort Link zu GitHub von MollySocket
zu Unterpunkt 2: siehe Flussschema im GitHub
zu deiner Frage 2: Es ist hauptsächlich wegen der guten Möglichkeit (kostenlos oder auch gerne mit einer Spende)
- die bestimmten Dienste zu nutzen, ohne den Aufwand des Selfhosting zu haben oder
- die Funktionalitäten der Dienste auf seine persönlichen Bedürfnisse zu prüfen vor seinem eigenen Selfhosting-Projekt
Ich würde mich freuen, wenn User, die Molly UP mit Push nutzen, Rückmeldung über den Akku-Verbrauch der ntfy-App geben könnten. 
Also ich kann dir sagen, ich bin sehr zufrieden. Der Akku Verbrauch ist besser als bei FCM.
Schließe mich @Figorino an, auch bei mir hat sich das Akku-Verhalten gegenüber WebSockets sehr verbessert! 
Habe das Problem das Nachrichten des öfteren erst erscheinen wenn ich Molly UP öffne, obwohl mir schon „lange vorher“ geschrieben wurde…
Nutze auch Rethink DNS, habe aber Molly UP und ntfy davon ausgenommen (Umgangen) und jegliche Beschränkung bei Netzwerk, Hintergrundprozess oder Akku deaktiviert.
Jemand mit ähnlichen Problemen…? Dankee
Falls man bedauerlicherweise nur selten Benachrichtigungen über Signal/Molly erhält, kann man übrigens die „UP-Example“ App von UnifiedPush benutzen, um die Funktion UP-seitig zu testen. Das „OK“ in Molly allein sagt m.E. nicht aus, dass wirklich Benachrichtigungen durchkommen werden.
Mir fiel dadurch nämlich auf, dass ich auf meinem neuen, privaten ntfy.sh Server noch eine entsprechende Berechtigung erteilen muss. Logisch, sonst ist MollySocket nicht zum publish auf dem privaten ntfy Server berechtigt.
Habe mir gestern auch die MollyUP installiert und es schien auch einwandfrei zu funktionieren.
Heute morgen musste ich aber feststellen, dass bei gesperrtem Gerät die pushs doch nicht Zeitnah verarbeitet wurden.
Ist es dafür unbedingt nötig MollyUP auch von der Akkuoptimierung auszuschliessen? Ich dachte dafür würde es nun mit ntfy reichen.