lucien

At the same time, those graph connections don't need to be persistent network connections. You could easily cycle through connected nodes and batch update events without issue, and in that case, the primary constraint is bandwidth to the connected graph, not network connections.

Those are definitely things to consider - I'm mostly thinking about technical constraints in scaling fediverse services out to meet large increases in demand.

I'd say that my wife is the organized one - she just makes it easy to take advantage of the organization and contribute content to it.

I think the main difference between fediverse and email WRT cache instances is that if you create a cache instance for email, you're only caching your personal emails. If you create a cache instance for a lemmy community, you're caching every event on the community.

My intuition says there's probably a breakpoint in community size where the cost of federating all events to the users who subscribe to them becomes greater than the cost of individually serving API requests to them on demand. Primarily because you'll be caching a far greater amount of content than you actually consume, unlike with email.

Edit: That said, scaling out async work queues is a heck of a lot easier than scaling out web servers and databases. That fact alone might skew the breakpoint far enough that only communities with millions of subscribers see a flip in the cost equation...

Maybe I should clarify with "each user successfully spun up..." I'm mostly curious if the 5000 microservers trying to federate is a more sustainable access pattern than 5000 users hitting the website.

Since federation is an async process, it can be optimized on both ends in a way that user browser requests cannot.

At the same time, federation would overall result in more bandwidth being used because not every user wants to view every post in the frontend.

The funny thing is that I've read it to him several times in the past. He just finally understood it well enough to do a double take and think "wait a minute, that seems like a terrible thing to do!"

Can't wait until my son is old enough that I can say "go hang out with your friends for a few hours" without being irresponsible.

My fave. Self-deprecating and fits the name well.

Medication, alarms, chore lists with reminders, project boards (jira @ work, notion @ home).

My wife and I keep EVERYTHING in notion. Our entire lives, pretty much any plan or thing we need to remember to do or communicate goes in that app.

I use other stuff on top of it, but notion has allowed us to split the mental load of managing our household much better than before. I have terrible memory, but I can no longer use it as an excuse. I've gone from "oops I forgot" to "oops I didn't set a reminder, what do I need to do to prevent this in the future?"

It wouldn't be exaggerating to say that the combination of process and home project management through it has saved my marriage. Oh, and I guess therapy helps. Find a good therapist if you can afford one.

Hm, so you're saying that for an individual who wants to self-host a single-user instance and interact with everyone else over activity-pub (e.g. post on lemmy communities and reply to mastodon toots), kbin may be a good choice?

It does seem to me that the multiple types of published events (threads / microblogging ) might allow someone to interact easily with both mastodon and lemmy in a near-native format, but I haven't tried using it like that.

Is that generally true, or only due to the DDOS protections? kbin.social has had to put in place. Those protections prevent it from federating correctly, but presumably once things calm down, it'll federate correctly again.

Maybe something closer to migration management in mastodon? Two groups of moderators on separate servers agree to a common set of moderation guidelines, publish an event or setting which says "these communities are merging", and from that point on they act like aliases for a merged community which share responsibility across servers.

These "merged" communities could be visually flagged as distinct from the normal rules / moderation of their respective servers to prevent conflicts arising from differences in server management.

Feature support would be limited by the server events are sourced from. E.g. if beehaw.org and lemmy.ml merged their technology communities, people on beehaw still wouldn't be able to downvote posts or see downvotes, but lemmy.ml would unless they explicitly disable to feature as a part of the merge contract.

When subscribing, you might see a list of merged communities which share responsibility for moderating the final one, and you have the ability to choose which "entrypoint" you use.

Spez answered a total of 14 softballs, and 7 more questions were answered by other employees with ultimately no satisfactory outcomes or answers. You didn't really miss much unless you like watching people pour gasoline on dumpster fires.