Oddbean new post about | logout
▲ ▼
Bashee Von Newmann | 2 months ago (raw) | root | parent | reply | flag 
 You can use a Golomb-Rice encoded list then. It can encode all the PKs in a compact way and the relay can expand it without needing to use any other data source. It doesn't have errors and it is less cpu intensive, specially for the relay. Take it into account.
▲ ▼
Vitor Pamplona | 2 months ago (raw) | root | parent | reply | flag 
 Isn't that in the same ballpark of what zip/zlib compressions alredy do? 

The Websocket connection can be compressed using gzip, etc. So, whatever we do needs to offer a significant again when compared to a an already compressed representation of the keys in hex strings.
▲ ▼
Braydon Fuller | 2 months ago (raw) | root | parent | reply | flag 
 Not sure how well gzip will compress filters, most cryptographic bytes do not compress well as they are usually high entropy.
▲ ▼
LeoWandersleb | 2 months ago (raw) | root | parent | reply | flag 
 Zip won't help much when compressing lists of pubkeys.

Even for a mobile client, uploading 67kB is not much, especially compared to what relays send in reply. If you want to make your client more responsive on startup, maybe you can query frequent posters first, to get something on the screen and send the full filter later.

If you consider involving the relay ... maybe we can reference collections of pubkeys via list events? The relay would get the relevant list event via it's naddr and then expand that list into the original query. Instead of {"authors":["c88821bdafd6c608107c9c4969672b57c3a8c85f2a0f6bc7b749c3c5609b3424"]}, {"authorLists":["naddr1qvzqqqr4xypzq3huhccxt6h34eupz3jeynjgjgek8lel2f4adaea0svyk94a3njdqy88wumn8ghj7mn0wvhxcmmv9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qqlgd6hyun9de6zq3n0d3kx7aeqf35hxapvyqcnzte3xqhnyvpjxvx3tr5w",...]}