Programmer, writer, philosopher.
Comment by ~yujiri on ~yujiri/sufec
As per our discussion in Matrix, a new sub-issue: maybe the NetworkPacket layer needs a time-to-live, a max number of hops, because it's possible for a packet to be sent in a circle: even though wrapped subtraction prevents you from overshooting the final recipient, it might be for example that peer 10 is the final recipient, peer 9 cannot reach peer 10, but peer 8 can - and the "closest peer" algorithm would lead peer 9 to transmit to peer 8.
Ticket created by ~yujiri on ~yujiri/sufec
Is there any way to do this in a peer to peer setting, without exposing information about what devices you have? (I think if conversation partners can see that information, the feature is crippled because it's reduced to a mere UX improvement on having separate accounts for separate devices that are each present in the room.)
Ticket created by ~yujiri on ~yujiri/sufec
The routing strategy used as of this writing involves forwarding ConnectionPackets through intermediate peers as necessary based on key distance. Compared to Tor, it has the advantage that intermediate nodes cannot tell whether the node they receive a packet from is the original sender or not.
But as per Drew's feedback, we also picked up a significant disadvantage relative to Tor: each intermediate node knows the final recipient, which Tor avoids.
Investigate other options. Can we have both benefits? Maybe there is a darknet or mixnet reliable enough to use as a transport? Or maybe we could use Tor as a transport after all?
Comment by ~yujiri on ~yujiri/sufec
I have gone ahead and implemented #2.
REPORTED RESOLVED IMPLEMENTED
Ticket created by ~yujiri on ~yujiri/sufec
We need NetworkPacket-level commands to request and announce peers. At a high level, it's simple enough: the RequestPeers packet will contain the sender ID, so the recipient can sealedbox back to them, and the AnnouncePeer packet will contain at least one peer encoded as ID + address + port. But as far as how a client should go about gathering a list of peers optimal for it to be directly connected to, there's a lot of hard questions to answer. Should re-read the Kademlia spec. On the bright side, this doesn't need to be part of the protocol strictly - any client can use its own approach. (That makes me wonder if the libsufec API should have a way to pass in an algorithm for this, and the actual algorithm should be defined in another crate.)
Ticket created by ~yujiri on ~yujiri/sufec
There are two main proposals:
A group chat has an ID generated by its creator. When you want to add a person to a group, you send them a Message saying they're invited, and send one to every existing member telling them about the new member. Each person's client must remember the group chat ID and the list of members.
- this may run into issues with desynchronization of group membership, since there is no single source of truth.
There aren't really group chats, it works like email: instead of a group ID, you just send the list of users with every message, and messages are grouped into "rooms" client-side based on whether they have the same set of recipients.
this will run into issues with UDP packet size: if you have 10 members, it takes 320 bytes per message just to store the recipient list. total overhead , and apparently the max UDP packets length that's safe in all environments is 508 bytes: https://stackoverflow.com/questions/1098897/what-is-the-largest-safe-udp-packet-size-on-the-internet
To deal with this, we would probably have to introduce new Message type(s) to indicate that a Message is being split across multiple packets.
Ticket created by ~yujiri on ~sircmpwn/aerc2
Aerc was working great for me until I sent myself a certain email that it doesn't like. As long as this email is in my inbox, loading displays this error message and the row where the email should appear remains loading.
The first time I saw this, aerc panicked a few seconds later: https://paste.sr.ht/~yujiri/f25a261c6532c86ad0db7283b0b99fea99eeb632
Every time since then, however, it never crashes and I'm still able to open other emails in my inbox.
I'm running Artix Linux and the error occurs with the packaged aerc 0.5.2-2, and also with a from-source build using master (1687e558).
I've pasted the exact content of the email as downloaded from Gmail's "Show original": https://paste.sr.ht/~yujiri/d5bdab5dd9b84035cb8cb3154988d89f4f4b3988