![](https://reddthat.com/pictrs/image/bb659a0f-b287-43f8-bfd8-7c05cbc3b1a0.jpeg)
![](https://reddthat.com/pictrs/image/be7232a2-91cc-4b25-acd6-dc4e99a7ccc2.png)
Yes, the issue is fixed, thanks for staying on top these issues 🙏
Yes, the issue is fixed, thanks for staying on top these issues 🙏
Leaving a link to the ticket for anyone interested: https://github.com/LemmyNet/jerboa/issues/1476#issue-2232272642
why is signal not an option?
Another thing to keep in mind, is that if the size of Lemmy.world is already causing so much problems, imagine what would happen with threads...
Technical problems aside, I am against big instances, a single entity holding so much power is a problem no matter who that entity is. I would suggest creating a policy against that, but it's hard to figure out concrete limits against such instances, maybe no instance should hold more than 50% of MAU?
Last but not least, as others have said, threads is known for their poor moderation. Cutting off trolls early is important in creating a healthy platform, the more space and attention you give them, the worse they get. Threads is not ready to deal with that, nor does it have the incentive to do so.
It sounds a bit too soon to use release names, especially given that Lemmy is still in alpha.
When a major release comes out, I suggest using colony names (fictional or real), like the pirate republic.
In general, I like names that highlight the decentralised aspect of the fediverse.
I thought Lemmy supported horizontal scaling for federation activities.
Wondering how many instances of the federation server reddthat is running and if increasing the number does anything for the issue.
Edit: It seems that 0.19 started synchronizating activities, so horizontal scaling is out of the question.
https://github.com/LemmyNet/lemmy/issues/4529
I think not. For example, the 2023 winner was from "Country: The Old Mermaid Townsfolk".
Unfortunately our backup script went a little haywire over this last couple months and it resulted in a huge bill regarding our object storage! This bug has been fixed and new billing alerts have been updated to ensure this doesn't happen again.
It's good to see guards being put into place, but don't stress too much about it. Mistakes happen, last week at my job we realized we had a monthly cronjob running every second, it was accumulating around 180M logs per month (or around 1,200$ per customer per month for gke logs alone)...
I haven't been paying close attention to funding, but I believe the instance has a relatively good runway. If that's not the case I would consider increasing my monthly contribution, just give us a heads up.
This has been a sore spot with me as it is most likely an implementation failure on my part and I curse to myself whenever postgres decides to restart for whatever reason. Even though it should not restart because I made a change on a separate service. I feel like I am letting us down and want to do better!
You make do with what you have, the Lemmy ecosystem is still young and you are a pioneer. Thanks for exploring these uncertain waters so others can follow along!
Personally, I think since October the instance has been pretty stable, of course there were issues like having to upload comment twice, but they are infrequent and for comparison during the same period GitHub had more than a couple of hour long outages...
As an attempt to breathe life into our communities, I've started a little Community Spotlight initiative. Where every 1-2 weeks I'll be pinning a community that you should go and checkout!
Noticed this and really liked it, makes the server feel so homely!! 🥰
As always, thanks for the update, it's so fun to be able to observe as this instance is evolving.
For anyone interested, Wikipedia provides some arguments against meritocracy.
https://en.wikipedia.org/wiki/Myth_of_meritocracy
Meritocracy is argued to be a myth because, despite being promoted as an open and accessible method of achieving upward class mobility under neoliberal or free market capitalism, wealth disparity and limited class mobility remain widespread, regardless of individual work ethic.
this is a method, and always was a method, I just wanted it to look like an attribute for aesthetic reasons
I think "aesthetic reasons" is an oversimplification. There are certain assumptions a developer makes when reading some code that uses properties. While these assumptions are not clearly defined and may differ per developer, I think there is a common core.
(1) There are no side-effects. The object is not mutated (or any other object), no IO takes place.
(2) The time and space complexity is O(1).
(3) The result is consistent. Consequent calls to the property should return the same value unless there is a mutation between them.
(tried to delete this comment but somehow didn't work, I re-read the article and have a different outlook, sorry for the low effort comment)
Maybe, you get to choose the point. What were the moments that made it all worth it?
As a developer that has used OSM, I want to fix the place classification for nodes in my country. At some point I realized that many region capitals were classified as towns when OSM policy states that they should be cities. It's been on my backlog for the past few months, and I want to dive deeper, understand the classification policy and create a script to fix mistakes.
I like the hot stove example, no matter how hard you think about it you will never be able to do it, unless you forget about it for a second. Though, ADHD is not that easy.
I know microsoft bad
I second that, big corp bad
PQXDH is designed for asynchronous settings where one user (“Bob”) is offline but has published some information to a server. Another user (“Alice”) wants to use that information to send encrypted data to Bob, and also establish a shared secret key for future communication.
Sounds to me like the equivalent of a product manager asking for blockchain features in order to save a failing startup.
As always I would say there is a huge "it depends".
For context, I am part of a small team of engineers, working on a relatively new product, we have continuous deployment setup for our release branches. We prefer many small PRs, think at least a PR a day per engineer.
I am responsible for setting up a new e2e test suite right now, so it's possible I reconsider later on. But, there are a couple lessons learned from our previous iteration.
I have been thinking about this for quite some time, feel free to add me on matrix (link in bio) if you are interested to collaborate/discuss.
It's interesting to consider a few potential use-cases, as you can see below the technical requirements for each use-case can be vastly different.
Notice, I am assuming that accounts are connected, aka if someone creates a post, that post can reach users of other instances. See the "Connecting Instances" section below.
Use Case: Organizing an Event
Let's say Alice wants to organize a trivia night at the coffee shop she works at. After all the preparations, Alice needs to invite people, so she makes a post with the location, the date, and the announcement of the event.
People following Alice's (or the coffee shop's) account, will be notified of the event and choose to either attend or not. Some may even "boost" the event, so it's reaches more people.
Discovery is not optimal. It's possible, people that live nearby the coffee shop, and would have otherwise attended the event, weren't following the account, as a result weren't notified and missed the event.
Instead, if a location based feed was available, it would have allowed people to find Alice's post and attend the event. The UX for such a feed can be complex, but the backend requirements are pretty straightforward, we need to filter (and/or sort) using the location, date and tags of an event.
All in all, the volume of data is small (not a lot of events happen at the same time and the same area), and the application is not time-critical (if a post takes several of minutes to reach other users it's not an issue as the event is posted days in advance).
Use Case: Short-Term/Live Monitoring
Let's say a group wants to organize a protest march, they know that the police tends to get violent on such occasions, so they need to monitor the police's activity and alert the people accordingly.
So, they create a system where some people are responsible for monitoring the area and regularly upload posts with the exact location of the police. This allows the group to create a map that shows the locations of police blocks and adjust their route accordingly.
While the example is terrible, I believe the use-case is clear. A lot of people, need to monitor "something" that is happening "right now".
Again, probably most of the complexity lies on the UX design, but a few backend requirements are added:
Keep in mind that (2) and (3) do not mean that a decentralized platform would be better suited.
Use Case: Long Term Monitoring
Let's say, during the spring, a population of ducks passes through the city. Tourists and locals alike want to watch the ducks, so they start recording sightings.
This information not only allows users that are nearby to rush to watch the ducks when there is a sighting, but also can be used to create a heatmap of the most probable locations to find ducks for a given time of day.
Technical requirements:
trigger warning
I had SA incidents in mind when writing the above example, but I choose a more light-hearted example to avoid needlessly triggering people.
The use-case is pretty much the same. The locations are places to avoid for safety reasons, and people rushing to the scene are either searching for the perp or helping/protecting the victim.
Use Case: Information Sharing
Let's say Bob learns an interesting trivia about the statue on the town square. He creates a post about the trivia and stamps it with the location of the statue.
Here, time is irrelevant to the post, people are going to be interested in Bob's trivia years down the line. However, people need to be able to discover Bob's trivia, and a map is probably the best tool for the job.
Technical requirements:
Connecting Instances
I don't think this would work, habbitat.world would still have users around the globe, as a result it would be queried every time someone refreshes their feed. You may make a case that there shouldn't be such an instance, but keep in mind (a) pretty much every Fediverse platform has a few huge instances, and (b) that would exclude users located in places without a local instance (or local instances with unethical admins/mods).
I believe the existing follow-based federation mechanisms would provide a better solution. Keep in mind that fedizens don't want to see "everything" within their feeds, but a curated list of posts/events based on their choices and/or the choices of people with similar background (same instance).