| Age | Commit message (Collapse) | Author |
|---|
|
on start, then managed by the client and stored once on client exit
|
|
the signal already open, it will be added as the first signal
|
|
"signal" and it's variants as this is the new terminology for "user
signals" which are direct messages between 2 users
|
|
|
|
so the client can use it to persist notifications
|
|
|
|
|
|
got to the top message but then more messages have been added
|
|
new messages in the frequency/receiver
|
|
|
|
|
|
|
|
components have updated instead of before so the view will reflect the
update in case any of the updates change the notifications
|
|
and sends the info to the client when it connects
|
|
they separate
|
|
|
|
|
|
|
|
how it looks lol)
|
|
|
|
and not save if it takes longer than 1 second
|
|
frequency, similar to how discord works
|
|
|
|
trusted and their public key mismatches and also ellipsis when the
username overflows the width
|
|
while in user signals
|
|
some things
|
|
|
|
|
|
will be selected, instead of just the selected message
|
|
network due to out of bounds indexing
|
|
|
|
other users even if the ping doesn't "ping" them
|
|
swap memberlist/banlist
|
|
|
|
user (which can be either receiver or sender)
|
|
user conversation
|
|
the user signals
|
|
|
|
in the user signals
|
|
|
|
|
|
|
|
|
|
will cause a desync and crash the server and show an invalid network on
the client side
|
|
|
|
|
|
banning
|
|
|
|
|
|
|
