To minimize clutter I imagine this would be a “sending” marker that disappears or transitions to a transient “delivered” marker. Thoughts?
I think this may be a good first issue and/or hackathon scope. Not sure though
I think this may be a good first issue and/or hackathon scope. Not sure though
I think this may be a good first issue and/or hackathon scope. Not sure though
Not sure what happened with the duplicates... Sorry for the spam
I'm thinking an indicator for "unsent" would be a nice, clear way to express this, and it would be friendly for people composing messages offline (to be sent later).
Implementing this primarily requires extending sprig's plumbing to create some local index of sent/unsent messages. Whenever we compose a message, we add it to this list. Whenever we send it (and get an ack from the relay), we remove it from the list. The list needs to be saved to and loaded from disk across application restarts. Once we can actually track this state, exposing it in the GUI is probably trivial.
Okay, so concretely here's what we need:
- A new service in
./core/message-state.go
that tracks the sent/unsent status of messages. This same service could potentially be responsible for read/unread tracking in the future, but let's not try to design any of that right now.
- this service should have a method to add a message to its registry of "unsent messages". This addition must quickly be stored on-disk so that unsent messages are preserved across application restarts. I think a JSON file is likely fine as an initial way of storing this data.
- this service should have a method to remove a message from its registry of unsent messages. This, too, must be updated quickly on-disk.
- this service should have a method for subscribing to changes in the set of unsent messages. This method return a
latest.Chan
containing[]string
(where each string is a serialized node ID).- The code that creates and sends messages in
reply-list.go
needs to be modified so that it marks the message as unsent before adding it to the store (adding it to the store sends it implicitly, as the sprout worker is watching the store for updates that need to be sent).- The code that actually performs a protocol-level "send" of messages needs to be updated so that it can mark the message as sent once the other end of the connection acknowledges it. This may require a small modification to
sprout-go
- The
reply-view.go
will need to be updated so that the view subscribes to changes in unsent status and tries a non-blocking read from the subscription channel at each call of it'sUpdate()
method. It should cache the latest set of unsent messages in a field.- Replies themselves, rendered by
widget/theme.Reply
will need to be modified so that they can display an unsent indicator. This can likely be added as another bitmask value in theReplyStatus
type. The reply status should be set to include "unsent" as part ofstatusOf
by consulting the cached list of node ids that have not yet been sent.As per the discussion in Thursday's Arbor sync, this issue is now offered with a bounty of 4 Coffees.