Could we perhaps get a general statement (perhaps semi-regularly) of how donated funds compare to server costs over time?

Hopefully this is readable. This is my favorite episode of this comic; it has a followup, which I'll link below, if you're interested.

Source

Followup 'Big Jack 2'

It's been all over Lemmy, but if you haven't seen it, this is what I'm referring to.

They're promising autonomy in the future but right now, it's just controlled remotely by a human user. I don't think that's a problem, and in fact, is actually an ideal final method for a specific use case.

If you were alive in the 90s, you probably remember the commercials for LifeAlert, basically a wearable for elderly people that could be used to contact emergency services if (for example) they fell and couldn't get up. That's the actual use case for this robot - a new take on LifeAlert. Imagine an elderly person with mobility issues (or whatever) just having this thing in their home. No autonomous functionality, but with the ability for them to call on it to help with whatever tasks they need help with, at which point a human in a remote location could take control of it, perform the task, and then have it go dormant again. This could be anything from "I need help lifting this thing" to "Help me put away my laundry" to "I've fallen and I can't get up". Basically, imagine someone who otherwise would need to live in a nursing home or other assisted living facility instead being able to live independently, getting help as needed from a remote assistant via the robot in their home.

Economically, it would likely be expensive, but a single remote worker could connect to and operate potentially hundreds of these things over the course of a single shift, making it much more economical than a live-in assistant, and much more of an on-demand service. If the agent could talk to the end user through the robot it could even be used for simple assistance like tech support or help reading a medication bottle.

Obviously this still has (some of) the privacy issues the actual advertised use case does, but it's maybe preferable to not being able to get help when it's needed.

...via this post.

Holy shit, why are we not leveraging this to the absolute maximum? Can we get furry emojis, pleeeease?

Canvas is a yearly Fediverse event similar to Reddit's Place - it's a collaborative art project where any Fediverse user can place colored pixels on a shared canvas over a period of a few days. It has a dedicated community at !canvas@toast.ooo - the canvas itself is here.

This will be its third year; the first time, there were some minor furry drawings, and last year, we were a bit more organized, with a bit of collaboration between Pawb and Yiffit. The full canvas from last year can be seen here - we had a small spot carved out in the lower left corner, as well as a few scattered things all around.

I'd be great to actually start organized this year, and create something substantial together.

Anyone else interested in participating? Any thoughts on what we might make? Anyone with artistic skill want to sketch something out? If we can get a few ideas, maybe we vote on them prior to the event itself?

Edit: Template Here

Just wanted you to know, @ickplant@lemmy.world, that your personal carrying of this community with daily bat pics was both noticed, and appreciated!

I'm sure you know, but I haven't seen any communication about it, so I'm bringing it up just to make sure. Performance tanked abruptly a few days ago and has only gotten worse in the following days.

Is it helpful to bring this up when it's observed, or would you prefer we just chill and wait?

Hugely improved performance! Great work! Thanks a lot!

Rather than communities being hosted by an instance, they should function like hashtags, where each instance hosts posts to that community that originate from their instance, and users viewing the community see the aggregate of all of these. Let me explain.

Currently, communities are created and hosted on a single instance, and are moderated by moderators on that instance. This is generally fine, but it has some undesirable effects:

• Multiple communities exist for the same topics on different instances, which results in fractured discussions and duplicated posts (as people cross-post the same content to each of them).
• One moderation team is responsible for all content on that community, meaning that if the moderation team is biased, they can effectively stifle discussion about certain topics.
• If an instance goes down, even temporarily, all of its communities go down with it.
• Larger instances tend to edge out similar communities on other instances, which just results in slow consolidation into e.g. lemmy.ml and lemmy.world. This, in turn, puts more strain on their servers and can have performance impact.

I'm proposing a new way of handling this:

• Rather than visiting a specific community, e.g. worldnews@lemmy.world, you could simply visit the community name, like a hashtag. This is, functionally, the same as visiting that community on your own local instance: [yourinstance]/c/worldnews
  • You'd see posts from all instances (that your instance is aware of), from their individual /worldnews communities, in a single feed.
  • If you create a new post, it would originate from your instance (which effectively would create that community on your instance, if it didn't previously exist).
  • Other users on other instances would, similarly, see your post in their feed for that "meta community".
• Moderation is handled by each instance's version of that community separately.
  • An instance's moderators have full moderation rights over all posts, but those moderator actions only apply to that instance's view of the community.
    • If a post that was posted on lemmy.ml is deleted by a moderator on e.g. lemmy.world, a user viewing the community from lemmy.ml could still see it (unless their moderators had also deleted the post).
    • If a post is deleted by moderators on the instance it was created on, it is effectively deleted for everyone, regardless of instance.
    • This applies to all moderator actions. Banning a user from a community stops them from posting to that instance's version of the community, and stops their posts from showing up to users viewing the community through that instance.
    • Instances with different worldviews and posting guidelines can co-exist; moderators can curate the view that appears to users on their instance. A user who disagreed with moderator actions could view the community via a different instance instead.
• Users could still visit the community through another instance, as we do now - in this case, [yourinstance]/c/worldnews@lemmy.world, for example.
  • In this case, you'd see lemmy.world's "view" of the community, including all of their moderator actions.

The benefit is that communities become decentralized, which is more in line with (my understanding of) the purpose of the fediverse. It stops an instance from becoming large enough to direct discussion on a topic, stops community fragmentation due to multiple versions of the community existing across multiple instances, and makes it easier for smaller communities to pop up (since discoverability is easier - you don't have to know where a community is hosted, you just need to know the community name, or be able to reasonably guess it. You don't need to know that a community for e.g. linux exists or where it is, you just need to visit [yourinstance]/c/linux and you'll see posts.

If an instance wanted to have their own personal version of a community, they could either use a different tag (e.g. world_news instead of worldnews), or, one could choose to view only local posts.

Go ahead, tear me apart and tell me why this is a terrible idea.