I suspect it has something to do with the HTTP Outcall lack of HTTP/2 support, but I can’t find anything in literature. Anyone know if this is the case?
It’s probably not your issue and not sure if it will help, but there are two common problems with HTTP outcalls that I’m aware of:
Lack of IPv6 support: The target API must support IPv6.
Identical HTTP outcalls answers: For one HTTP outcall, multiple requests are triggered and their responses should be identical. For example, this can be ensured with an idempotency key.
The latter is probably not your issue given your error message, maybe the former?
Great points. The APNS server allegedly only supports IPv6, so not sure if that is the problem. I don’t understand enough about HTTP/2 but I suspect that that IC Outcalls are HTTP/1.1.
Hi, thanks for letting us know about the problem. I suspect the reason the requests fail is that the HTTPS outcalls adapter does not support HTTP/2, and it is listed a requirement to connect to APNS in the apple developer docs [0].
At 2.66 cents per push notification, this seems expensive, especially at scale. For an active user sending 50 messages a day, that’s $1.33 daily or about $40 per month just in notification costs.
Am I off base here, or is this indeed prohibitively expensive for a messaging app? Has anyone found ways to optimize this or implement alternative solutions?
Interested in hearing your experiences and thoughts on handling this at scale.
If I understand correctly, 20B is allocated for a 2MB payload. You need to calculate the size of the outgoing payload, but if you send 20B and your outgoing call only uses, say, 1B, then the remaining 19B will be refunded to your canister. So, it’s essentially a ‘pay-as-you-use’ model.
Thanks for weighing in! So after turning down the allocated cycles to what I actually need to send a push notification, the cost ends up being 65,730,665 cycles (which by my math is approximately $0.000087 per notification). Its actually pretty reasonable! Not quite as cheap as a standard web 2 server, but still fairly reasonable.
The real challenge with these outcalls is the idempotency. I was able to implement outcalls straight to the APNS server, but it technically sends 10-20 push notifications at a time. Apple provides a way for client apps to handle that but its pretty inefficient.
Anyways, if anyone is interested in checking out the app, shoot me a DM and I’ll add you to the testflight.
So I wrote an e2e encrypted messaging app to learn more about ios development with the IC and e2e encryption in general. I use the apple push notifications to then initiate a query of my canister and pull the actual data down.
Yes, it does send a group of notifications (sometimes 10ish sometimes 20ish), but using the apns-collapse-id field in the push notification package, ios does a decent job only displaying it once. Sometimes it buzzes 2-3 times.
When I am in the app, i wrote a little logic to handle the idempotency, so its not an issue, but its not an elegant solution.
It was much better when I used a google cloud server to filter through and only send one notification, but I removed that because it kind of defeats the decentralized purpose.