seems so, also from my reading in the kuketz-forum, for some it just works and others have issues. too bad being on the wrong side 
Updated my Molly to official v8.2.2-3 today. No change. After the device has been sleeping for an hour or so it doesnât beep anymore using UP 
For me it seems to work quite stable with latest ntfy (not integrated but extra install) and latest Molly plus push server https://ntfy.yourdevice.ch and Mollysocket via https://mollysocket.yourdevice.ch - I get all notifications in time and all the test-notifications via UP-Example and Molly come through immediately.
The only thing I am still not 100% sure is the ringing of signal calls because I get so very fewâŠ
I am currently experimenting with Molly (using my secondary phone number), with built-in ntfy (using https://push.murena.com) and MollySocket from adminforge.de (https://molly.adminforge.de).
If you open ntfy, you get a list of all subscribed topics. Selecting one topic (e.g. for Molly) displays the topic URL push.murena.com/<some value>. You can share it and open in your favourite browser to get an overview of the sent push notifications.
Today, I was also affected by the missing push notifications from Molly. There seems to be a considerable delay between the sending of the message and the alert of the UnifiedPush server to push the message to my smartphone.
Hence, the message seems to get delayed or lost in the chain Signal messenger => Signal servers => MollySocket => UnifiedPush server. I cannot say which is the culpritâŠ
Yeah, but this is another server. Should the molly.adminforge.de server be the problem? Testing it.
Yes, why not.
Canât say where exactly but yourdevice.ch somewhere on its website states that one should not mix their mollysocket service with other push servers, it would be safer (in terms of functionality) to only use their push server and their mollysocket as a combo.
Who knows, from the above statement maybe it is the combo of murena push (or other) with a different mollysocket-provider that gets prone to errorsâŠ(?)
But I had issues with only using adminforge services as wellâŠ
BTW, my UP-Example app does currently not work with push.murena.com. No registration happens - maybe the UP-Example server has a problem with the Murena Push server because of the certificate problem (that has been resolved), e.g. because the wrong certificate has been cached?
Correction: As has been observed in UnifiedPush / Fennec - The push service application is no longer available - #11 by obacht, the problem was my version of UP-Example: Version 2.2 works, the preview of 2.3 (available in F-Droid) does not.
1 Like
It seems indeed to work with https://mollysocket.yourdevice.ch. Perfectly!
2 Likes
The admin(s) at yourdevice.ch have added push.murena.com to the list of allowed domains for their MollySocket. I could register my Molly instance and will see whether the behaviour improves.
If yes, we should contact adminforge.de and inform them of this strange problem.
1 Like
Just a hint as it was not yet mentioned but might be relevant as well: In case of changing the Mollysocket provider it is recommended to manually delete the previous one in Molly which means deleting the specific âlinked deviceâ before connecting to the new one.
1 Like
After several days, I can confirm @irrlichtâs experience, Molly works as expected. I have decided to completely migrate from Signal to Molly because I like the concept of UnifiedPush.
Two additional observations:
- ntfy (also the built-in /e/OS variant) allows to switch to WebSockets for its push connection, which I have done. It may be a placebo effect, but I think that the battery performance has slightly improved.
- I have remembered that microG has introduced a temporary doze whitelist feature several years ago, see Sign in to GitHub · GitHub If microG receives a FCM push notification for an app, the app is woken up and Android informed to let the app run even in doze mode. I think that this would be great for ntfy.
- Do you think that the temporary whitelisting is a reasonable feature request?
- If yes: As this feature needs the installation of ntfy as a system app, should the feature be proposed upstream in ntfy, in the /e/OS backlog, or both?
1 Like
Hello @obacht, @irrlicht & @mihi, I have opened a topic on the adminforge.de forum, see MollySocket: Verzögerte Zustellung beobachtet - adminForge Services - adminForge Community.
The admin of adminforge has explained that the problem is known and that they have already tried several things to fix it.
They have also set up a new instance with a new database at https://mollysocket.adminforge.de. If you are inclined, you may test whether it works.
EDIT: Please share your experience here, mine has been positive so far (around 24h).
2 Likes
The admin of adminforge.de will reset the database for molly.adminforge.de (i.e., the default MollySocket) tomorrow, 2026-04-08. The delayed and missing push problems will then (hopefully) be fixed, and we should be able to switch back to molly.adminforge.de.
2 Likes
didnÂŽt have the time and nerves to test because I relied on the function in the past days but will give it a try in the coming days 
thanks @Tentos for getting in touch with adminforge!
Edit @Tentos
Can you clarify which push server your testing is based upon?
Always push.murena.com with integrated
foundation.e.ntfy (Version 1.17.8-4) or different from that?
1 Like
I will try to switch back to molly.adminforge.de tomorrow and share my experience here. mollysocket.adminforge.de has worked so far , so there is hope that the problem will be fixed.
1 Like
It seems that the reset has happened, see Signal: MollySocket-Datenbank Reset - adminForge
I have switched back to molly.adminforge.de and will share my experiences. Note that mollysocket.adminforge.de is already offline.
EDIT: After 12h, push has worked reliably so far. I will see whether this is the case in a couple of days.
EDIT 2 (topic has been automatically closed): No problems yesterday, too. I will continue to check the notification arrival in the next days.
EDIT 3: Unfortunately, I have experienced some delay (from 30s to 2 min), which seems to have started around noon, April 11. Letâs see whether this persists.
EDIT 4: The problem has returned. The (temporary?) fix was to re-register my Molly instance with molly.adminforge.de again, as described at WebSocket to Signal frequently closed with code 4409 ("Connected elsewhere") â no pushes until manual connection ping · Issue #102 · mollyim/mollysocket · GitHub
Can you, on molly: disable UnifiedPush, go to Linked devices settings and unlink âMollySocketâ, then set UnifiedPush again ?
1 Like
This topic was automatically closed after 90 days. New replies are no longer allowed.