Has anyone else had issues receiving push notifications via iOS apps from their Akkoma server? I’m having trouble with Metatext, and the new Feditext branch of it, in particular. The other user on my server connects via the Mastodon app, and gets push notifications through it just fine, but Metatext and Feditext are silent for me. Any configs or logs I should look into?
Seems like an issue with Feditext then, no? I think it’s better you ask there. They’ll know what you can expect in regards to push notifications or not. Especially since it is working from another app from what I understand, this doesn’t immediately seem like an Akkoma issue.
I agree that signs point to Feditext. I have asked there as well, but it felt reasonable to check whether, like other differences among the various ActivityPub implementations, there was some known difference in Akkoma’s notification setup that apps commonly trip over. Both Metatext and Feditext show me push notifications for Mastodon instances I have them connected to.
Lots of Mastodon apps work badly, or not at all, with Akkoma (and presumably Pleroma).
For notifications, sadly, the official Mastodon app is the best. I say sadly as it lacks on pretty much all other areas. However, most of the new “breed” of Mastodon apps won’t even let me log in with my Akkoma account. It “feels like” (but I do not know this) they are checking some meta data string somewhere, and if it doesn’t say “Mastodon” they pretty much stop dead in their tracks and doesn’t bother with looking at actual requests/responses.
The best app on iOS that I’ve used for Akkoma, lately (as Metatext is dead) is Mona For Mastodon, which has most of the features working alright. But alas, not notifications, so I have to run the official Mastodon app as well, just to get a notification on when I am to open up first Mona, and secondly the Mastodon app to clear the notifications.
Usually I just stick to the Akkoma web interface in my mobile browser though (in my case Firefox), which obviously won’t give me notifications, but all of the rest of the functionality.
Thanks for the response, Mathias. Knowing it’s not “just Metatext” might offer some guidance for investigation.
I’m also enjoying the pleroma-fe interface, on both desktop and mobile. I saw somewhere that mobile notifications should improve on iOS later this year. If that does happen, I might just stick with the PWA.
Interesting! I’ve tried it both ways, OTP release to get started, but now I’m compiling my own. Neither has worked for Metatext notifications. But I wonder if this points to some config. Actually … are we all running Akkoma behind nginx like the setup guides demonstrate, and could that have anything to do with it?
I definitely run nginx. One of the few things in the stack on the server I actually properly “know” and can tweak as I like without thinking it was all luck.
When an official release (e.g. 2023.05) comes out, I check which git commit matches that release and I compile from source at that commit. I assume the OTP release would be the same git commit, but bundled with its own runtime.
EDIT: I also run nginx and this is my Erlang version:
# Some webpush clients (e.g. iOS Toot!) use an non urlsafe base64 as an encoding for the key. # However, the web push rfs specify to use base64 urlsafe, and theweb_push_encryption library # we use requires the key to be properly encoded. So we just convert base64 to urlsafe base64.
That looks like it’s using plain base64 and not url-safe base64.
I wonder if those of us who are receiving push notifications are either using an app that encodes the auth key for the subscription as url-safe base64, or just happen to be lucky enough that the url-safe base64 encoding of their key is the same as the url-UNsafe base64 encoding.
I’m not too excited about getting the Xcode project set up to build a modified version of Feditext (and get the Apple developer keys aligned for APNS). So modifying Akkoma to check and log whether Key == ensure_base64_urlsafe(Key), and/or just letting the url-UNsafe version through to try it, may be what I attempt.
I wouldn’t call it conclusive, but this base64 encoding looks likely to me. I added this code to Pleroma.Web.Push.Subscription.create, right before the Repo.insert:
case ensure_base64_urlsafe(key_auth) do
^key_auth ->
Logger.warn("This key was already URL Safe")
safe_key_auth ->
Logger.error("This key was NOT URL safe (orig: #{key_auth}) (safe: #{safe_key_auth})")
end
When I sign in via Feditext, I get the “NOT URL safe” message, and never receive push notifications. When I sign in via the Mastodon official app, I get the “already URL Safe” message, and finally receive notifications.
I’m going to go let the Feditext folks know about this, and hopefully a change can be incorporated into their beta soon, and we’ll see if it has any effect.
In the meantime, I think it’s also interesting that the replacement of characters that the ensure_base64_urlsafe function does, doesn’t seem to fix the problem. In theory it ends up being the same value when decoded, right? I even logged out and back in enough times to see a key value logged that had the same value before and after except for the equals signs on the end (which are “optional” in the spec, and indeed the Mastodon key is two characters shorter than the Feditext key), and still didn’t receive notifications. So, it’s possible that this is not the issue. If there’s some sort of signing that happens, and the data being signed uses the encoded key and not the raw key, maybe? But I think I’m done digging for the night.
