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.

People stranded on the roof of a hospital in Tennessee after hurricane Helene

Video

Video

Wild flooding in Ashville, NC due to Hurricane Helene

Video

@bender@twtxt.net I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected.

@bender@twtxt.net I believe it is Unix-Unix Copy Protocol. Not Unix Copy-Copy Protocol.

83(4) GDPR sets forth fines of up to 10 million euros, or, in the case of an undertaking, up to 2% of its entire global turnover of the preceding fiscal year, whichever is higher.

Though I suppose it has to be the greater of the two. But I don’t even have one euro to start with.

I’d like to see them fine me 2% of zero dollars

@david@collantes.us having offsets were nice because it gives you context of where the user is in relation to you.

@prologic@twtxt.net thanks. I hate it. Might as well use UUID