Push notifications

[jb55]

trafficstars

This is a tracking issue to get push notifications out the door

• [ ] https://github.com/damus-io/damus/issues/1707 (We should at least test to see if current behaviour is acceptable)
• [ ] #2400
• [ ] #2443
• [ ] #2444
• [ ] https://github.com/damus-io/damus/issues/2574
• [x] #2434
• [ ] #2437
• [x] https://github.com/damus-io/damus/issues/1701 (Nice to have, but we already have code we can reuse for this from Damus Purple)
• [x] https://github.com/damus-io/damus/issues/1704 (Absolutely necessary)
• [x] https://github.com/damus-io/damus/issues/1733 (Absolutely necessary)
• [x] https://github.com/damus-io/damus/issues/2200 (New one that I added, which will be necessary to execute this new plan)
• [x] #2322
• [x] https://github.com/damus-io/damus/issues/1706 (Probably needed, but I am not a legal expert to know for sure)
• [x] #2399
• [x] A fair bit of notifications show completely unformatted (usually reactions?)
• [x] #2360
• [x] #2323
• [x] #2403
• [x] #2397
• [x] #2398
• [x] #2324
• [x] Rewrite it Rust (Spike/Hacking experiment) for improved performance
• [x] #2388
• [x] #2408
• [x] #2417
• [x] #2418
• [x] #2427
• [x] #2419
• [x] #2420
• [x] #2435
• [x] #2436

[alltheseas]

What is the dependency on waiting for permissions from apple @danieldaquino ?

[alltheseas]

What is the dependency on waiting for permissions from apple @danieldaquino ?

Do we have an issue for tracking the apple permissions?

@jb55 cc @danieldaquino meta-comment on issue of issues tracking: I re-arranged the issues to having the pre-requisite/mandatory tickets at the top, and the nice-to-haves and/or uncertain tickets towards the bottom. If yall agree we can carry forward this practice for issues of issues.

We can also carry forward this practice for milestones - most important issues at top, least at bottom.

[danieldaquino]

@alltheseas

What is the dependency on waiting for permissions from apple @danieldaquino ?

For this particular plan, none. Here is an excerpt of an email containing relevant context:

(...) we might be able to roll it out whether or not we have the Push notification filtering entitlement.

Will mentioned that we do not yet have support for encrypted mute lists (we don’t create them, and we do not parse them either).

Since we do not have support for that yet (Most mute lists on Damus are presumably public), we can perform mute filtering on the server-side based on those public lists (without worsening user’s privacy). If we do that, then having the entitlement does not make a difference until we have encrypted mute lists.

Given that state of affairs, Will mentioned it will be worth rolling out that feature regardless of whether we get the entitlement or not.

[danieldaquino]

most important issues at top, least at bottom.

Love it, 100% agree we should use that convention

[alltheseas]

bumping to current sprint based on previous standup discussion with @danieldaquino

[alltheseas]

Moving to 2.0 milestone, as we wont have sufficient time to test for 1.9 AppStore release

[danieldaquino]

I setup the server and published a testflight to start testing push notifications in a real environment.

It seems to be working in some occasions, but alas I am hitting a "PayloadTooLarge" error frequently. It seems that we might be hitting a 4KB payload limit

[alltheseas]

Reply with a quote note mentioned

[alltheseas]

Update settings to reflect push notifications

[jb55]

I setup the server and published a testflight to start testing push notifications in a real environment.

It seems to be working in some occasions, but alas I am hitting a "PayloadTooLarge" error frequently. It seems that we might be hitting a 4KB payload limit

I'm guessing because its sending kind3 events anytime someones contact list changes. I get spammed with these (for smaller lists). we should fix that.

[jb55]

multi-device seems to work!

[danieldaquino]

Spent a few hours (about 2~3 h) trying to port the plugin logic to Rust. I could not get it to work in this time, but I was able to port a "skeleton" over and solve a lot of compiler issues. In the end there are still a significant amount of compiler issues to resolve, but I think it's reasonable to keep going at it, it seems promising.

My WIP draft so far: https://github.com/danieldaquino/noteguard/commit/477cb6dd4d5e13c88271927c3b049195640efe7f (does not fully compile yet)

[danieldaquino]

Spent a few hours (about 2~3 h) trying to port the plugin logic to Rust. I could not get it to work in this time, but I was able to port a "skeleton" over and solve a lot of compiler issues. In the end there are still a significant amount of compiler issues to resolve, but I think it's reasonable to keep going at it, it seems promising.

My WIP draft so far: danieldaquino/noteguard@477cb6d (does not fully compile yet)

@jb55 if you agree this looks like the best way to go, I can create a ticket so that I can work on it further

[jb55]

On Mon, Jul 08, 2024 at 06:09:58PM GMT, Daniel D’Aquino wrote:

Spent a few hours (about 2~3 h) trying to port the plugin logic to Rust. I could not get it to work in this time, but I was able to port a "skeleton" over and solve a lot of compiler issues. In the end there are still a significant amount of compiler issues to resolve, but I think it's reasonable to keep going at it, it seems promising.

My WIP draft so far: https://github.com/danieldaquino/noteguard/commit/477cb6dd4d5e13c88271927c3b049195640efe7f (does not fully compile yet)

thanks! I'll take a look and start hacking on it.

[jb55]

On Tue, Jul 09, 2024 at 08:30:02AM GMT, William Casarin wrote:

On Mon, Jul 08, 2024 at 06:09:58PM GMT, Daniel D’Aquino wrote:

Spent a few hours (about 2~3 h) trying to port the plugin logic to Rust. I could not get it to work in this time, but I was able to port a "skeleton" over and solve a lot of compiler issues. In the end there are still a significant amount of compiler issues to resolve, but I think it's reasonable to keep going at it, it seems promising.

My WIP draft so far: https://github.com/danieldaquino/noteguard/commit/477cb6dd4d5e13c88271927c3b049195640efe7f (does not fully compile yet)

thanks! I'll take a look and start hacking on it.

I've rebased it onto the apns branch, I am working on it there

[jb55]

On Mon, Jul 08, 2024 at 06:11:38PM GMT, Daniel D’Aquino wrote:

Spent a few hours (about 2~3 h) trying to port the plugin logic to Rust. I could not get it to work in this time, but I was able to port a "skeleton" over and solve a lot of compiler issues. In the end there are still a significant amount of compiler issues to resolve, but I think it's reasonable to keep going at it, it seems promising.

My WIP draft so far: @.***(https://github.com/danieldaquino/noteguard/commit/477cb6dd4d5e13c88271927c3b049195640efe7f) (does not fully compile yet)

@jb55 if you agree this looks like the best way to go, I can create a ticket so that I can work on it further

I think a better approach is to have a noteguard filter that is basically a "forwarder". a way to write notes over a socket/websocket to somewhere else.

This would allow us to set up an APNs daemon/relay that doesn't care about the details, traits, or run lifetime of noteguard. We just need to make sure the forwarder reconnects, etc.

The cool thing about a notification relay is that it wouldn't need to write to disk, so people could push private events to it. It could be anywhere. We could also run it on a different server and have a standalone endpoint that people could push events to:

https://notify.relay.damus.io

although we might want to put noteguard in front of that as well for rate limiting, lol.

We also wouldn't have to worry about encryption on the endpoint that receives the device tokens, as it could be a part of the same server.

I am hacking on noteguard today so I can put together a forwarder filter.

[danieldaquino]

@jb55 I got notepush to work, with some intermittent issues that I am trying to fix. Latest runnable code is pushed to master on the notepush repo! I will keep fixing remaining issues

[jb55]

On Wed, Jul 31, 2024 at 02:47:44PM -0700, Daniel D’Aquino wrote:

@jb55 I got notepush to work, with some intermittent issues that I am trying to fix. Latest runnable code is pushed to master on the notepush repo! I will keep fixing remaining issues

awesome, I'll take a look!

[danieldaquino]

@jb55, updates on notepush:

• Fixed the intermittent issues I was facing. It feels stable now from local testing!
• Changed mutex architecture to dramatically improve performance potential and reduce shared resource contention
• Fixed an issue where it would never format
• Merged your Cargo formatting PR.
• Improved notification fallback formatting (Probably addresses https://github.com/damus-io/damus/issues/2323)
• Stopped sending notifications for random nostr event kinds (should address https://github.com/damus-io/damus/issues/2322)

We reached (and passed) feature parity with the previous Deno solution! strfry-push-notify is obsolete

[danieldaquino]

@jb55 forgot one:

• Unified Web API and Websockets interface. Now both the API and the websockets relay can be accessed through the same port without issues

All code is pushed to master in notepush

[danieldaquino]

@alltheseas @jb55, after https://github.com/damus-io/damus/issues/2360 is closed, I suggest that we try deploying and rolling out an internal testflight for internal testing. As all server-side code was completely rewritten, the list of issues in the description may have changed significantly.

[danieldaquino]

@alltheseas @jb55 I am configuring a notepush deployment on our servers for testing. I will post more updates in this ticket soon

[danieldaquino]

Actually I will post updates on deployment on https://github.com/damus-io/damus/issues/2384 😅

[danieldaquino]

2024-09-02 updates on push notifications:

• Deployed staging push notification environment which can be used with dev builds
• Sent a PR that allows damus to connect with the staging environment or with a custom notepush server: https://github.com/damus-io/damus/pull/2415/commits
• Sent a PR that should fix #2403: https://github.com/damus-io/damus/pull/2416
• Sent a notepush PR with 3 fixes/improvements: https://github.com/damus-io/notepush/pull/6
  • I already deployed these changes on our server (for prototype testing)
• @jb55 if you have a chance to use the new staging environment with a local build and debugger, can you please let me know about the error logs/error codes you are seeing on the push notification extension?

CC @jb55 @alltheseas

[jb55]

• @jb55 if you have a chance to use the new staging environment with a local build and debugger, can you please let me know about the error logs/error codes you are seeing on the push notification extension?

I'll test this today

[danieldaquino]

• @jb55 if you have a chance to use the new staging environment with a local build and debugger, can you please let me know about the error logs/error codes you are seeing on the push notification extension?

I'll test this today

@jb55 were you able to get some info on the error codes/logs you are seeing on the extension?

[alltheseas]

Continue to receive generic reactions on 1.10 (8) with onlyzaps on

[alltheseas]

Continue to receive someone zapped you 1.10 ;8)

[danieldaquino]

I suspect @alltheseas's issue might be related to having a large NostrDB database file. I have no evidence yet, but just a gut feel — I can't imagine another reason at the moment. I opened a ticket to track this: https://github.com/damus-io/damus/issues/2437

[alltheseas]

Behavior from today