North Carolina
Interested in Linux, decentralization, cryptography, golang/rust/c, and communication.
Working on Arbor Chat.
discussion added by ~whereswaldon on ~whereswaldon/arbor-dev
feature added by ~whereswaldon on ~whereswaldon/arbor-dev
sprig added by ~whereswaldon on ~whereswaldon/arbor-dev
Ticket created by ~whereswaldon on ~whereswaldon/arbor-dev
The current notification policy sends a notification when a new node is added to local storage that meets the following criteria:
- the node was not authored by the local Identity
- the node is either a reply to a node authored by the local identity or a new conversation
Unfortunately, this means that a user connecting for the very first time from a new device gets notified of every new conversation from the past.
The question is, what's the right policy to suppress this? I think that a sane choice would be to limit notifications for new conversations back to a particular point in time, but which point? 24 hours? What if you just don't open the app for 2 days? Do we care that you miss conversations that occurred a day ago?
We could also try recording the last time you had the app running and notify only for conversations since that point in time. If that point is undefined, then we don't notify at all. This seems compelling, but it may have some downside that I haven't seen yet.
Thoughts?
Comment by ~whereswaldon on ~eliasnaur/gio
I am also unable to reproduce this now. Thanks for the quick fix!
Comment by ~whereswaldon on ~eliasnaur/gio
Up until today, I'd not been able to trigger this bug on the version of Go's master branch prior to your CL, but it finally happened. The version of Go with your CL applied did run the same code successfully. I know that this issue is closed, but I wanted to share that we now have stronger positive confirmation that the fix was correct.
Ticket created by ~whereswaldon on ~eliasnaur/gio
I accidentally discovered today that the
internal/rendertestpackage appears to have nondeterministic results when run on X11 with an NVIDIA GPU.Here are the results of running the tests ten times consecutively.
This was done with NVIDIA Driver 440.82 on a GeForce GTX 960.
Nothing trips the race detector, so I assume that whatever is happening is likely in the CGO, maybe within NVIDIA's GL implementation?
Comment by ~whereswaldon on ~whereswaldon/arbor-dev
I see your point. Perhaps long-pressing the message should filter? The button could then serve as a backup for people who don't like that kind of implicit action.
Fanning the buttons is possible, but it's complex. Generally we only want the primary action to be a floating button on the bottom, and I don't know that filtering is the primary action. It bears thinking about...