mikedilger / gossip Goto Github PK

I think this will trigger the other VueJS listeners much less often, so the front end doesnt get bogged down

Allow them to enter multiple relays

We should wait for a new minion to signal the bus before we message it.
Otherwise that message may never reach them (if they didn't clone a receiver yet).

Never display it (but possibly PKCS export it later on)

Add Drop traits to always zero out the memory.

Store it in the database encrypted with a PIN number that they enter to use it.

Add Drop traits on the PIN number too.

'ready' is a command the front end should call to the backend. The backend should not send javascript events until it is ready, it should queue them.

'render' is a flag in pinia which a rust message will turn on. It should stay off until rust has uploaded all of its changes. It disables taking any action on pinia changes that are subscribed to... but it itself is subscribed to and when it goes on the actions then occur.

These should improve performance and responsiveness.

Right now on broadcast, every minion hears every other minion's messages back to the overlord. That's wasteful. Use an mpsc to send back to the overlord.

1. Read from database
2. Then read from relays until EOSE or a timeout
3. Then filter, sort, and translate into Posts (front-end data)
4. Then send to front end in a single event

This process can be repeated if the user changes their filter/sort parameters.

Not sure about subsequent events. Right now we can just forward them through, but we might want to redo all of that, compute a diff, and send over the diff (just an idea still).

Not required for alpha-next.

On startup, fetch missing user data:

Query relays for type-0 metadata with no 'since' date, and pick the latest metadata to fill in their data.

and add a pivot table to remember which relays the event was seen on.

by marking the event they delete as 'deleted'

And don't let person_relay.last_fetched get in the way of this change (because it will as currently written).

metadata map is empty right now

I have to tab out and back to get the new events.

I found at least one place where I have to convert from IdHex to Id (which is the harder conversion direction).

Right now it says client needs a restart.

possibly r2d2-sqlite or tokio-sqlite

Or somehow figure out if we can have many readers at once (I know it's only 1 writer, but can you have that writer going while readers are also going?)

Right now it just has events with pubkey and name on them. We need a separate list for these.

Hide a post. This doesn't delete the post, nothing gets saved. If you restart it comes back.

Might need to signal the backend since the backend aggregates.

RelayPicker works now, we should switch to it

nostr/mod and webscoket handler shuld be combined into a Minion.

Make the minion build the filters. Overlord can use RelayPicker and send it the relay and keys.

We should still update last_fetched even if we don't get an EOSE.

Initially the values are really wrong.

Even sub-minute seconds are not ticking over.

turn last_fetched into last_fetched_feed (which looks back at most one feed_chunk, even the very first time)

create a last_fetched_other (which looks all the way back the first time).

Option to follow people without publishing that into your follow list.

Option to auto-secretly-follow all new people encountered.

When we follow someone, we don't get their entire history. But people will want to 'load more' at which point we should query an older date range.

Sometimes the feed loads with dateago values that are way off, and tabbing out and back fixes them.

Minion should get its OLDEST last_fetched date to use in the 'since' filter.

Should update on EOSE.

The feed is coming through unsorted

The dates are unused.

But we should count how many times a minion serving a relay died, versus how many times we have used that relay.

This is partial. We still need to add an image.