What specific features are you looking for?
All of this user’s content is licensed under CC BY 4.0.
What specific features are you looking for?
Can you ping the Jellyfish server from the laptop? Can any other device access the Jellyfish server?
Plus I cringe at the thought of 75% of the CBC budget being spent on content moderation.
Theoretically, could they outwardly federate only? For example, they make a post which gets pushed out to other instances, but they would set their instance to not allow any external posts or comments to be federated into their instance, and they could close registrations. That way, the rest of the Fediverse could follow and interact with their content, and they wouldn’t have to deal with moderation. I’m not sure if that’s really how federation works, so please correct any inaccuracies.
[…] treat each Lemmy community as a community, not an audience.
I think it depends on the community in question, and the nature of the post. If, for example, one is looking for an answer to a question, or help with something, I would argue that one would, generally, want to target the largest relevant audience to maximize the surface area of potential people who can help. At any rate, more specifically, I don’t think it’s one or the other, but rather both — one would want to find the largest and the most relevant community. By my experience, another common behavior is to cross-post to multiple communities. This seems to be especially more common in a federated forum like Lemmy where there could be any number of duplicate communities.
I know I can post and be the change I seek.
Imo, this is your answer. I’m not sure exactly what other solution you want. Content will not appear on Lemmy without someone first posting it. Advertising the platform to help draw people in is also important.
I will preface by saying that I am not casting doubt on your claim, I’m simply curious: What is the rationale behind why it would be so unlikely for such an exploit to occur? What rationale causes you to be so confident?
Looks like a Fractal Node 304?
Yep! I’ve found that the case is possibly a little too cramped for my liking — I’m not overly fond of the placement of the drive bay hangars — but overall it’s been alright. It’s definitely a nice form factor.
It wasn’t a deliberate choice. It was simply hardware that I already had available at the time. I have had no performance issues of note as a result of the hardware’s age, so I’ve seen no reason to upgrade it just yet.
For clarity, I’m not claiming that it would, with any degree of certainty, lead to incurred damage, but the ability to upload unvetted content carries some degree of risk. For there to be no risk, fedi-safety/pictrs-safety would have to be guaranteed to be absolutely 100% free of any possible exploit, as well as the underlying OS (and maybe even the underlying hardware), which seems like an impossible claim to make, but perhaps I’m missing something important.
“Security risk” is probably a better term. That being said, a security risk can also infer a privacy risk.
Yeah, that was poor wording on my part — what I mean to say is that there would be unvetted data flowing into my local network and being processed on a local machine. It may be overparanoia, but that feels like a privacy risk.
You’re referring to using only fedi-safety instead of pictrs-safety, as was mentioned in §“For other fediverse software admins”, here, right?
One thing you’ll learn quickly is that Lemmy is version 0 for a reason.
Fair warning 😆
One problem with a big list is that different instances have different ideas over what is acceptable.
Yeah, that would be where being able to choose from any number of lists, or to freely create one comes in handy.
create from it each day or so yo run on the images since it was last destroyed.
Unfortunately, for this usecase, the GPU needs to be accessible in real time; there is a 10 second window when an image is posted for it to be processed [1].
[…]
- fedi-safety must run on a system with GPU. The reason for this is that lemmy provides just a 10-seconds grace period for each upload before it times out the upload regardless of the results. [1]
[…]
Probably the best option would be to have a snapshot
Could you point me towards some documentation so that I can look into exactly what you mean by this? I’m not sure I understand the exact procedure that you are describing.
[…] if you’re going to run an instance and aren’t already on Matrix, make an account. It’s how instance admins tend to keep in contact with each other.
This is good advice.
Fediseer provides a web of trust. An instance receives a guarantee from another instance. That instance then guarantees another instance. It creates a web of trust starting from some known good instances. Then if you wish you can choose to have your lemmy instance only federate with instances that have been guaranteed by another instance. Spam instances can’t guarantee each other, because they need an instance that is already part of the web to guarantee them, and instances won’t do that because they risk their own place in the web if they falsely guarantee another instances (say, if one instance keeps guaranteeing new instances that turn out to be spam, they will quickly lose their own guarantee).
How would one get a new instance approved by Fediseer?
A likely comparatively barebones (but sufficient for my needs) solution that I use is Obsidian with Synching.