This is pretty neat! An IP KVM that doesn’t cost a gagillion dollars. I might just back it. https://www.kickstarter.com/projects/jetkvm/jetkvm

Well poop. Covid coming to visit for a second time.

@prologic@twtxt.net currently? it wouldnt :D.

we would need to come up with a way of registering with multiple brokers that can i guess forward to a reader broker. something that will retry if needed. need to read into how simplex handles multi brokers

Yes a redirect to my profile uri. because its crazy long and ugly

@doesnm@doesnm.p.psf.lt Agree. salty.im should allow the user to post multiple brokers on their webfinger so the client can find a working path.

I am reminded of this when I look at entire forks of vscode just to add a LLM code completion assistant.

Yeah.. it is very similar to salty.im a smp is a relay queue for messages. You can self host one if you choose. They also have something called xftp for data storage and device state transfer. You can also self host one.

Is anyone here on simplex? https://sour.is/simplex

Same! Great joke!

i like this one

@movq@www.uninformativ.de i’m sorry if I sound too contrarian. I’m not a fan of using an obscure hash as well. The problem is that of future and backward compatibility. If we change to sha256 or another we don’t just need to support sha256. But need to now support both sha256 AND blake2b. Or we devide the community. Users of some clients will still use the old algorithm and get left behind.

Really we should all think hard about how changes will break things and if those breakages are acceptable.

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

here are plenty of implementations https://www.blake2.net/#su

I mean sure if i want to run it over on my tooth brush why not use something that is accessible everywhere like md5? crc32? It was chosen a long while back and the only benefit in changing now is “i cant find an implementation for x” when the down side is it breaks all existing threads. so…

These collisions aren’t important unless someone tries to fork. So.. for the vast majority its not a big deal. Using the grow hash algorithm could inform the client to add another char when they fork.