![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.world/pictrs/image/41e39366-cb91-4d4a-bc07-a47621cb7d5f.jpeg)
Or…. “Typical”…. 😉
This is a stupid question.
Adrian’s digital basement is an awesome channel, he’s a goofy guy that really loves the older hardware and does it justice.
You might be dying. Idk
I’m now on time. People notice my punctuality, no one actually cares.
Seems like a lot of people are unaware of white pages
He just wanna do hoodrat stuff with his friends
Yep, I don’t disagree, just wanted to make it clear what is shared and what isn’t. I suppose if you don’t like people training AI on the text you write, then you may not like that they could gather it with literally no effort. Most other sites would require that they put some effort either into web scraping, using an api to request the post, or just buy the content in some text dump format.
But ya, I mean, this is a minor difference between platforms, overall.
It’s not and never claimed to be. Lemmy is a piece of software, the instance owners and community moderators choose what stays and what’s goes, every Lemmy instance is just a glorified forum of old internet. Federation means the post isn’t solely controlled by the instance owners, but deletion is federated so the instance deleting it sends notice to every other instance where it exists to delete it as well, and then it’s up to that instance to do it (tho Lemmy will do this automatically so it would require altering the server code to stop that)
So, on that topic of “security” - just remember that whenever you post, your post is essentially sent to every “instance” that is federated (and listening for the community you posted to). Each instance is it’s own server running it’s own version of an activitypub implementation (lemmy, mastadon, etc).
So on lemmy.world that means your post is sent to literally thousands of servers that you cannot directly influence. If you delete a post, a request is made to those servers to also delete the post, but if that instance is modified or unavailable when the request is sent (it’ll re-try, but there’s a limit how many times), then it’s possible your post will not be deleted and you’ll never know.
Keep in mind this also means that anyone, say a government or private company, can establish an instance, federate, and receive the posts of everyone. Their instance may be nearly completely invisible - so you won’t know they’re collecting that information.
However, lemmy stores and sends almost no information about any user. A user profile does not contain IP address or country or anything. All of that stays in the server logs of the instance you originate from, and never enters the database. So your “true” personal information isn’t shared, but your account name, and a link to your account, and the post content (whatever text you add) is shared.
Lastly, images tend to be shared. Lemmy uses “pict-rs” which is a FOSS image hosting server, and when an instance receives a federated post, if there is an image in the “URL” field, then it will ask pict-rs to download that image to its server for easier serving to its users.
You mean like my friend fiction? Like the story where the whole basketball team becomes zombies and then they all fight over dating me?
Butts butts, I love butts.
If you want to federate, then yes. Your instance needs to accept the activity pub messages sent by the instances you federate with. You would also need to send out the apub notices whenever you do activity on your instances
You can solve your “problem” by running your own instance and federate with whoever you want
ITT a bunch of fuckheads who don’t understand how federation works, and thinks that lemmy should be a free-for-all with infinite ‘freedom of speech’
Jesus, go host your own instances, there’s literally nothing stopping you. it’s as easy as editing a config file and running a single command. Why people find defederation some major sleight i’ll never understand.
The search process basically works by looking for the “@” sign in the search term, if the name isn’t found locally, then it uses the apub process called “webfinger” to identify the instance and request the information from it. This process relies on the host server being online, correctly receiving the request, correctly responding, and then your server correctly ingesting that response before emitting the reply to you.
So if no one on your instance has already gone through this process, then there’s a couple chances for the chain of actions to fail, but once that community is “subscribed” and created locally, then your search without the “@” will fetch the “local copy”. Once that local copy exists, it “announces” itself to the home instance, this then tells the home instance to start emitting all the apub info to your local instance (new posts, comments, votes, etc).
So I believe what you’re seeing is first the get_communities
takes a while to go through all of that. Because of that, while waiting the UI sets the results to “empty” until the actual return comes in, once the results come back and the UI updates the state, you see the community in the list. But until that community is “copied” locally, you can’t manually go that community from your local instance url simply because it doesn’t exist locally yet.
The issue also comes down to the fact that no instance needs to update. So if you’re requesting a v0.17.x instance community from a v0.18.x instance, the api’s changed and they may not communicate properly to your home instance. I’m sure there are other points of failure too.
But I believe the lingering “pending” state should be mostly fixed, if you’re using an instance that’s on 18.3 then I don’t think you should encounter that much…
EDIT: It should be noted, that once you search for the remote community, it will fetch the entire community, including all posts and comments, and populate the cache (which I believe lasts for 3 days as of 18.3 unless someone subscribes to it, at which point it’s effectively “saved” locally). This means big communities might be extremely slow to respond to the apub request
It would be better to replicate the db into a purpose built search engine like elasticsearch or TypeSense, and then modify the UI to use that. It’s dumb for lemmy to implement a search engine when there are better more supported systems out there. This isn’t really a lemmy feature, imo, outside of supporting deployments using those types of products.
I recently submitted a PR for stopping pictrs image federation. IMO the images themselves do not need to be downloaded when served by another pictrs instance. This would reduce the amount of diskspace and reduce the burden of hosting images that are unwanted by the instance owners.
What are your thoughts on this, and do you think this will be merged? https://github.com/LemmyNet/lemmy/pull/3799
I’m sorry but I’m shocked mac has 1/5 share - wtf who wants that garbage
It depends on the source. Lemmy uses “pict-rs” as the built in image hosting mechanism, this includes a way to fetch small thumbnails. But other hosts, like catbox.moe or Imgur or anywhere else might not be being fetched efficiently.
Additionally, pict-rs uses imagemagik to transform the image on request. If that transformation doesn’t already exist (cached), or the host is over-loaded or under-spec’d, then you might see a delay in the request response
Your best bet is to use your developer tools to check network usage and response times if you are interested