zicklag.katharos.group
Software engineer and problem solver with a passion for producing high quality solutions to real-world problems. I strive to make great things that people can use and enjoy, all to the glory of God.
239 posts
351 followers
45 following
Regular Contributor
Active Commenter
comment in response to
post
I think that it's important to have those solutions, but our focus is mostly on public groups, and basic non-public communication where convenience is more important than maximum metadata elimination / obfuscation.
comment in response to
post
Good question. I think that is generally out-of-scope for Roomy.
I won't say it's impossible that we look into it eventually, but we're not aiming to be a competitor to things like Session or Signal, which are focused on ultimate privacy / anonymity.
comment in response to
post
Until our architecture settles more, though, we're disabling direct messages to reduce scope and focus on public spaces, knowing that the Keyhive ( formerly Beehive ) system we're planning on building on will provide E2EE that we should be able to use for that once we're more settled.
comment in response to
post
Our plan for the next iteration of the architecture will support E2EE DMs and group chats stored _off_ of the PDS so that people can't just download the encrypted data and store it for later to try and brute force it or wait for a key to be leaked.
comment in response to
post
The current version does store encrypted DMs on the PDS, but it's not so great because the encrypted data can be downloaded by anybody.
We are working on some data overhauls right now, and we are planning on temporarily pulling out direct messages to focus on public groups.
comment in response to
post
Great episode!
comment in response to
post
Watching now, and I so much agree with what you said at 1:02:05.
I've found the same thing: that I have to be OK building something and then investigating it all the while to find the simple, underlying pieces of it so that I find what I _actually_ need, based on the simpler common pieces.
comment in response to
post
Just to add more resources to this kubernetes alternative dev resources thread, this project could be useful. Work in progress but it's a neat idea:
github.com/drpcorg/chot...
It's a kind of CRDT data store, but made on top of LSM trees like RocksDB, LevelDB, etc.
comment in response to
post
I hadn't thought of that.
I was initially thinking that wasn't possible without a custom PDS implementation, but I forgot we could use service proxying to a service that would convert the opaque blobs into JSON or something like that.
We might be able to do that, thanks for the idea!
comment in response to
post
That does mean that chat messages are essentially a "black box" as far as ATProto can tell.
They are stored in blobs that can't be parsed without understanding the format and the messages inside aren't described by a Lexicon.
comment in response to
post
We actually only save compressed bundles of chat messages to the PDS periodically.
That keeps the record usage on the PDS much lighter, and it's easy to avoid surpassing the rate limit.
All of the realtime synchronization happens appart from the PDSes and ATProto.
comment in response to
post
Love this piece! Excellently written. 💖
It feels like having this could really boost community productivity. Help people help each-other to make something great. Solve the endless question of how to "manage" a project without killing it at the same time with organization and procedure.
comment in response to
post
We collectively have to figure out how to start funneling the value that we're producing back to us from users so that when our current well runs dry our contributions don't dry up too.
I think this is an important point to make!
comment in response to
post
I think the disconnect is that people see "leeching" as them getting something without putting anything into it.
The message that you're trying to point out is more along the lines that we as developers are "leeching" off the VC funding in the same way that Bluesky PBC is at the moment.
comment in response to
post
The other analogy that has been made is that open social protocols should be like roads, that everyone can use.
So I’m asking, what’s the plan for taxes?
comment in response to
post
I ran into the same issue only knowing how to do navigation on a grid when I started my game years ago.
Polyanya didn't exist at the time, so I never tried it out, but I've wanted to see it used somewhere since I learned about it.
comment in response to
post
Cool! What are you using for the navmesh? Home-made or an existing library?
comment in response to
post
Hey, just this morning me and @zeu.dev were talking about how were were going to handle rich text in Roomy and decided that facets seemed like the way to go.
I opened a discussion just now around whether we could get some standardized facets to work with for common markdown-type styling.
comment in response to
post
side note: having a lot of fun reading @erlend.sh's blog posts on Weird, related projects / visions, and Muni Town, the emergent scene of ppl working on these and related projects in the "open social web"!
see blog.muni.town :)
comment in response to
post
But to make that simple core useful you have to combine it with more protocol, because it's all about choosing one value and never changing.
That's why we have to have multi-paxos, and then people make all kinds of variations on things.
That makes it trickier to define "Paxos".
comment in response to
post
I'm not 100% sure yet, since I haven't tried to implement it myself.
I haven't spent time to fully grasp this paper, but I think this is good too.
The author of Paxos mentions how the original paper was more confusing than necessary, and that fundamentally it is almost as simple as possible.
comment in response to
post
I think Paxos is not as complicated as people make it out.
This post even formalizes Paxos on top of Automerge, which we're using for our CRDT in @roomy.chat.
medium.com/@polyglot_fa...
I haven't gone though that yet, but eventually I want to experiment with something similar.
comment in response to
post
Our solution, which was reasonable in our scenario for now, was just to run a Redis instance for handling all the data that needs transactions or strong consistency.
But I did want to explore ways to build small pieces of strongly consistant data on top of CRDTs, such as tiny Paxos implementations.
comment in response to
post
Ooh, that's really interesting, thanks for sharing! I added to it to my notes so I don't forget about it.
We actually had that same issue Garage is describing in weird.one, where we were trying to build on top of an eventually-consistent system, but needed name reservation to be strongly consistent
comment in response to
post
Still might need small, strongly consistent pieces on top of that, though.
I have a hunch that a lot of the cluster configuration could be safely eventually consistent so that you get partition resilient self-management.
comment in response to
post
One of the biggest goals for me was being lightweight and having a masterless architecture so you could trivially add nodes to the cluster and the cluster would manage itself.
The CRDT / eventually-consistent stuff I'm working on seems like it might help and replace RAFT.
comment in response to
post
I absolutely believe that declarative infrastructure needs more work, and that k8s is generally exhausting and overcomplicated.
I've wanted to make an alternative for a while, but don't have the time. 😅
comment in response to
post
Almost... Still fixing a little bit. 😆
comment in response to
post
It's no wonder I always have more trouble than makes sense trying to put scrolling containers inside of flex layouts.
Definitely a relief to learn, though. ☺️
comment in response to
post
But flex items, on the other hand, wouldn't stop expanding out of the parent no matter what I did, because the min-width is automatically set to auto, so that it won't get smaller than it's content, and won't trigger clipping / scrolling.
comment in response to
post
On a normal div, if you do things to make sure the container doesn't grow outside of it's parent, it will happily clip the box if you set the overflow to clip.
comment in response to
post
"Is anyone still reading? Is this thing still on? I sure hope so."
Yep!
Waiting for part three now. 😄
comment in response to
post
"Put differently, it’s the equivalent of replacing your engine oil with Crisco. Your car may still run, but you are absolutely voiding the warranty.
But, but, but — and I stress the stammer — voiding your warranty does not mean your engine will become broken!"
comment in response to
post
I was wondering if we could do something where hovering over a chat message would grey out or dim all of the chats that weren't visible when that chat was posted.
comment in response to
post
We were thinking that read receipts would be something private by default, but could be optionally made public.
And even without explicit "read receipts", it is always possible to know which chats were visible when somebody makes a new chat.
comment in response to
post
Also, every time you chat, the document explicitly knows the "parent commits" so to speak, so you can actually go "back in time" and see what chats were visible when somebody posted a message.