If people have to hack your privacy-respecting browser to make it respect their privacy, maybe your privacy-respecting browser isn’t really privacy respecting.
James Endres Howell has moved reshared this.
@andre @FinalOverdrive I mean, the funny thing is: “why is my house on fire? Also, don’t reply with the obvious: ‘because you doused it in gasoline and lit a match.’”
🤷♂️
reminds me of "Social Distance and the Patent System" -- judges keep getting software patent cases wrong because they're more likely to have patent lawyers in their network than working programmers
forbes.com/sites/timothylee/20…
Today it's easy for a company to chain-hire execs who are inside the Big Tech consensus reality and out of touch with the regular web
At least it's just about:config, it doesn't require you to download the source code, apply patches might might break in the next version, then compile again.
Firefox is bad at the moment and people should be aware that privacy focused forks exist, but developers maintaining Chromium forks are having a worse time. Times are hard for those seeking privacy. 
I had to move to a new instance last week. I followed these instructions and it went perfectly smoothly. Didn't lose a single follower (or follow).
fedi.tips/transferring-your-ma…
@FediTips deserves a shoutout! Very grateful!
Kim Possible reshared this.
Woohoo! 🥳
Thanks, have a nice time on your new instance! 👍
James Endres Howell has moved reshared this.
📷: Pope Francis visits the Holy Trinity Humanities School in Baro, near Vanimo, Papua New Guinea, Sept. 8, 2024.
The two most upvoted comments on any Lemmy instance are on Feddit.dk, but you won't see them on your own instance
I recently discovered an interesting (and somewhat disappointing, as we'll find later) fact. It may surprise you to hear that the two most upvoted comments on any Lemmy instance (that I could find at least) are both on Feddit.dk and are quite significantly higher than the next top comments.
The comments in question are:
1. This one from @bstix@feddit.dk with a whopping 3661 upvotes.
2. This one from @TDCN@feddit.dk with 1481 upvotes.
These upvote counts seems strange when you view them in relation to the post - both of the comments appear in posts that do not even have 300 upvotes.
Furthermore, if you go on any instance other than Feddit.dk and sort for the highest upvoted comments of all time, you will not find these comments (you'll likely instead find this one from @Plume@lemmy.blahaj.zone).
Indeed, if you view the comments from another instance (here and here), you will see a much more "normal" upvote count: A modest 132 upvotes and a mere 17 upvotes, respectively.
What's going on?
Well, the answer is Mastodon. Both of these comments somehow did very well in the Mastodon microblogging sphere. I checked my database and indeed, the first one has 3467 upvotes from Mastodon instances and the second one has 1442 upvotes from Mastodon instances.
Notice how both comments, despite being comments on another post, sound quite okay as posts in their own right. A Mastodon user stumbling upon one of these comments could easily assume that it is just another fully independent "toot" (Mastodon's equivalent of tweet).
Someone from Mastodon must have "boosted" (retweeted) the comments and from there the ball started rolling - more and more people boosted, sharing the comments with their followers and more and more people favorited it. The favorites are Mastodon's upvote equivalent and this is understood by Lemmy, so the upvote count on Lemmy also goes up.
Okay, so these comments got hugely popular on Mastodon (actually I don't know if 3.4k upvotes is unusual on Mastodon with their scale but whatever), but why is there this discrepancy between the Lemmy instances then? Why is it only on Feddit.dk that the extra upvotes appear and they don't appear on other instances?
The reason is the way that Mastodon federates Like objects (upvotes). Like objects are unfortunately only federated to the instance of the user receiving the Like, and that's where the discrepancy comes from. All the Mastodon instances that upvoted the comments only sent those upvotes directly to Feddit.dk, so no other instances are aware of those upvotes.
This feels disappointing, as it highlights how Lemmy and Mastodon still don't really function that well together. The idea of a Lemmy post getting big on Mastodon and therefore bigger on Lemmy and thus spreading all over the Fediverse, is unfortunately mostly a fantasy right now. It simply can't really happen due to the technical way Mastodon and Lemmy function. I'm not sure if there is a way to address this on either side (or if the developers would be willing to do so even if there was).
I personally find Mastodon's Like sharing mechanism weird - only sharing with the receiving instance means that big instances like mastodon.social have an advantage in "gathering Likes". When sorting toots based on favorites, bigger instances are able to provide a much better feed for users than smaller instances ever could, simply because they see more of the Likes being given. This feels like something that encourages centralization, which is quite unfortunate I think.
TL;DR: The comments got hugely popular on Mastodon. Mastodon only federates upvotes to the receiving instance so only Feddit.dk has seen the Mastodon upvotes, and other instances are completely unaware.
like this
echomap, etai, originalucifer and AlexanderESmith like this.
like this
Fitik likes this.
like this
Aatube likes this.
like this
originalucifer likes this.
Discouraged, but still supported. There is also another FEP (forgot the code now) being worked on and implemented by Mitra.
The point is that it is possible for an instance to federate an activity which is not originated by them.
I seriously doubt Lemmy currently does any validation whatsoever. There were communities using this blatant security issue for non-malicious purposes (see endlesstalk.org/c/tails@lemmon… which re-wrote posts from people (which is only possible if the posts weren't validated, or at least re-fetched from their origins)).
There is a way to re-share and validate remote activities, either through LD signatures (ew, JSON-LD processing :vomit:) (which only Mastodon and Misskey implement) or the newfangled FEP-8b32 Object Integrity Proofs (which nobody relevant on the microblogging space implements).
There were communities using this blatant security issue for non-malicious purposes (see endlesstalk.org/c/tails@lemmon… which re-wrote posts from people (which is only possible if the posts weren’t validated, or at least re-fetched from their origins)).
The reason this is possible is because of the way Lemmy federates activities.
When you on instance A post, comment or upvote something in a community on instance B, your instance sends the activity to instance B, regardless of the instance of who you're replying to or upvoting. It is sent to the community, and the community then shares it out to all other instances. AFAIK, lemmy does nothing to verify that received content from a community actually comes from the original instance. See here for one of the main Lemmy devs commenting on this..
Is this secure or reasonable? I'm honestly not sure but it doesn't feel great. Signatures on objects could fix this I think.
Instead of sending the entire object embedded in the activity the secure way would be to only the URI instead. This is permitted by JSON-LD.
In the receiving side, if the object is untrusted (i.e. if it isn't signed or if it's from a separate authority from the parent object containing it) it should be thrown away and the id should be fetched from the remote instance directly (same as it would happen if it was a URI instead of an inline object). This is completely an oversight on Lemmy's implementation and not a protocol problem.
like this
originalucifer likes this.
and given this is AP, that’s gonna be a while. People seem to love bikeshedding in circles instead of doing actual work
Out of curiosity, what do you mean by this? Any examples? I've not followed the development of AP very much at all honestly so I don't know the history.
this issue is a blocker for mastodon not supporting filtering remote posts by words (which would've helped with many spam attacks, which the pleroma family supported just fine for a WHILE via MRF, and more recently misskey has added support for)
if you go to socialhub you'll find MANY threads of reasonable ideas that are in json-ld representation bikeshed hell as people unnecessarily debate over which exact json-ld representation of the same exact data is the most correctest. the most infuriating recent ones i have seen is the emoji reaction fep discussion and FEP-fb2a: Actor metadata both of which does this bullshit ON FEATURES ACTIVELY FEDERATING RIGHT NOW, where changing it would BREAK BACKWARDS COMPATIBILITY
I recently started looking at socialhub actually. I have even participated in that emoji reaction thread you linked, but I only joined the site recently.
Honestly, I'm a bit confused by the site. There's kind of a lack of direction in a sense? Everyone is trying to extend the protocol in various different ways and it seems difficult to achieve alignment and agreement. I guess that is to be expected in a decentralized system but still.
you’ll find MANY threads of reasonable ideas that are in json-ld representation bikeshed hell as people unnecessarily debate over which exact json-ld representation of the same exact data is the most correctest
What's the alternative though? I mean nobody has the authority to put their foot down and decide. I agree that the debates go on for way too long, but how else do we find alignment? Then again, the long discussions definitely exhibits a kind of selection bias - only the people who are pedantic enough to keep discussing will do so. Everyone else naturally just get tired of the whole thing and leave.
It's weird but it almost feels like the fediverse needs a benevolent dictator to kind of get an overview and set a clearer direction, when it comes to the standards.
this bullshit ON FEATURES ACTIVELY FEDERATING RIGHT NOW, where changing it would BREAK BACKWARDS COMPATIBILITY
But these features were totally non-standard extensions right? You can't expect such things to continue being compatible as the actual standard evolves. It would also be a neat way to strong-arm the standard - just implement an extension in the way that you want it to work and now the standard has to keep your version compatible. That wouldn't be good. Just because there exists a non-standard implementation does not mean it should be able to dictate how stuff should be done.
But these features were totally non-standard extensions right?
that's the thing, everything in activitypub is a non-standard extension. hashtags are an extension. post visibility the way it's commonly done is an extension (more like a convention in that it doesn't introduce anything new, but still not written down anywhere official), the concept of an un-locked account is a convention (and the marker that marks an account as locked is an extension). pinned posts, marking images as sensitive, they're all extensions
(surprisingly, this is the second time i'm writing this exact thing today)
It’s weird but it almost feels like the fediverse needs a benevolent dictator to kind of get an overview and set a clearer direction, when it comes to the standards.
this has historically been mastodon. and they have put themselves in such a place that anything they do not approve of gets seen as a "nonstandard extension" and anything they approve of gets seen as a part of the standard. see the above reply.
edit: additionally, emoji reactions are federated by the SECOND MOST POPULAR free/open AP software and has implementations in at least 5 other software families (not just forks of one software, entire software families). if they cannot determine a de-facto standard but mastodon can, is AP really an open standard?
Yea I see what you mean. How do we solve this though? I mean let's say you were to redesign the protocol from scratch. Do you just need to include all these things into the protocol from the start? That's a lot of features and considerations to make. An extensible protocol might be for the best? But it does bring a lot of complexity... I'm really not sure.
this has historically been mastodon. and they have put themselves in such a place that anything they do not approve of gets seen as a “nonstandard extension” and anything they see gets seen as a part of the standard. see the above reply.
Yea this is problematic, especially because this pulls AP into a more microblogging-oriented direction, at the expense or at least disregard of all other use cases. I would not call this a benevolent dictator - that's just a regular dictator.
(surprisingly, this is the second time i’m writing this exact thing today)
Where? I'd love to read more about this stuff.
Indeed mdon like-federation seems weird but I presume it was setup this way for efficiency, to reduce the number of small communications? Although Lemmy has a backend in rust - more efficient than mdon's ruby - still I wonder whether the lemmy system of federating all upvotes would scale well if the number of users grows to that of mastodon and beyond ? Could there be some intermediate compromise solution (e.g. federate batches of 100 likes)?
still I wonder whether the lemmy system of federating all upvotes would scale well if the number of users grows to that of mastodon and beyond ?
It's a good question and really we just don't know yet I think. It's very hard to predict performance of complex systems. The only way to know, is basically by measuring, and the only way to do that is if we actually had that amount of users.
Could there be some intermediate compromise solution (e.g. federate batches of 100 likes)?
Unfortunately ActivityPub has no way to "batch" activities like this.
like this
dcpDarkMatter likes this.
like this
Fitik likes this.
Then why, if I view the post on feddit.dk, does it not show me those likes/votes? What is dependent on my instance?
I don't understand what you mean, how does it now show you the likes? If you see the two comments here and here as I linked above, you can see the high upvote count. Almost all the upvotes are from Mastodon instances.
The upvotes do not appear if you view the comments from another instance, like here and here, because those instances did not receive the Like.
Your instance doesn't pull the upvotes from other instances. That would not be scalable. How would it know when to pull again, to see new upvotes? When would it stop pulling periodically? Never? And you'd have to do this for every single post and comment everywhere.
No, instead ActivityPub uses a push mechanism here. So any new activity is pushed out to the ones that are deemed relevant to know about the activity. Any other instances are unaware.
Pulling the data when a user requests a post/comment (with a cooldown/cache for popular posts) isn't any more or less scalable than feddit.de pushing the same data whether it's been requested or not. If anything, I'd think pushing data when it's not necessarily needed would be less scalable.
But if it has to be a push model, why doesn't feddit.dk push the votes it knows about along with the rest of the data?
Pulling the data when a user requests a post/comment (with a cooldown/cache for popular posts) isn’t any more or less scalable
That would definitely be less scalable. That would entail pulling every single time a user views a post or comment. That's simply not feasible. There are far, far more views of content than there are posts, comments and votes.
Also what about stuff that isn't seen? What if nobody is logged in or nobody looks at the New sort? You need the votes before you even show the user anything, otherwise you can't sort the votes.
But if it has to be a push model, why doesn’t feddit.dk push the votes it knows about along with the rest of the data?
This has been explained elsewhere in the thread, see feddit.dk/post/7628338/1025556…
True, but that's why I mentioned a cache or cooldown. Once every two minutes is plenty, unless Lemmy really blows up and we have hundreds of instances trying to fetch a very popular post.
You have a point about new sort, but you could approximate it by sorting what's known to an instance. It's not ideal, but it's at least something. Maybe it would make sense to push just that feed, or to fetch a subset periodically.
I read that comment tree, but it doesn't answer my question. If someone on Mastodon likes a post on feddit.dk, I don't see any reason feddit.dk can't communicate that to lemm.ee when I go look at it.
Once every two minutes is plenty,
That won't work, because it would have to be once every two minute for every single comment and post forever.
You have a point about new sort, but you could approximate it by sorting what’s known to an instance. It’s not ideal, but it’s at least something. Maybe it would make sense to push just that feed, or to fetch a subset periodically.
I have no idea what you mean by this - you can't fetch a feed, that's not at all how the data is organised.
If someone on Mastodon likes a post on feddit.dk, I don’t see any reason feddit.dk can’t communicate that to lemm.ee when I go look at it.
The problem is this: How does lemm.ee know that the like that feddit.dk claims is from mastodon.social actually is from mastodon.social? What prevents feddit.dk from just fabricating a like from mastodon.social? Currently there is no nice mechanism for authenticating such a forwarded like. A malicious instance could send loads of likes claiming they come from other instances.
like this
etai, originalucifer, themadcodger and Fitik like this.
at the minimum the followers of that user should be notified about that like…
I agree - the problem is that the instance that sends the Like (on instance A) doesn't know the followers of the user receiving the Like (on instance B), because followers are not (necessarily) public. So it doesn't know which instances to send the Like to. And instance B can't forward the Like to the followers itself, because the signatures in ActivityPub are not made for that, as I explained elsewhere in the thread.
like this
originalucifer, themadcodger and Fitik like this.
however they than just forward this reply to the follower collection
How do the receivers of this indirect activity verify that the activity was indeed produced from the original instance?
It simply can’t really happen due to the technical way Mastodon and Lemmy function. I’m not sure if there is a way to address this on either side (or if the developers would be willing to do so even if there was).
Mastodon needs to implement group support, you can follow the issue here (don't get your hopes up though).
like this
Fitik likes this.
like this
Fitik likes this.
A Mastodon user stumbling upon one of these comments could easily assume that it is just another fully independent “toot” (Mastodon’s equivalent of tweet).
Wait, back up... Mastodon calls these "toots"? So, everybody is posting farts?
Can't even see these posts, I clicked and got:
400
{"error":"couldnt_find_post"}
like this
Fitik likes this.
PS: I just tried it without Photon and got another error.
feddit.nl/post/feddit.nl/20706…
Anyway, all good and not something I can influence so I let it go 
Mastodon doesn't support groups so it's maybe not a "bug" per se, but it is at least a missing feature.
Consider also that if Lemmy shared upvotes the same way, you would only see the upvotes on posts from your own instance, i.e. upvotes would only appear on the local feed. The all feed would be pointless and in general it would be pointless to try to sort posts across the whole fediverse, as you only receive upvotes for your local posts.
Lemmy simply would not function if it shared votes like that. So in that sense, it's a bug kind of. And as mentioned above, I think it's a bad way of doing it, as it encourages centralization.
(mentioning people mentioned in post because post mentions apparently do not work)
ACTUAL NEWS: The Democratic ground game is badly underfunded
Found 11 new servers and 14 servers died off since 3 hours ago.
22,742 servers checked. 13,600,851 Total Users with 1,051,686 Active Users today. Check out the stats!
New #fediverse servers found:
using-archaic-words.isbrill.com a #wordpress server from United Kingdom
mstdn.flowers a #mastodon server from Singapore
blahaj.felifluid.de a #sharkey server from Germany
ojikey.kmkz.moe a #sharkey server from Japan
cryptid.house a #sharkey server from The Netherlands
social.ajg0702.us a #mastodon server from Private
akko.faraday.quest a #akkoma server from United States
shkey.cakestwix.com a #sharkey server from Private
social.freedombits.org a #pleroma server from United States
030fb8f04baed7d1.simple-url.com a #mitra server from Finland
misskey.shinamonlifelog.uk a #misskey server from Private
Help others find a home, send them to fediverse.observer
Via Rupar:
Liz Cheney on ABC: "I've been voting for 40 years. My first vote was for Ronald Reagan in 1984. I've never voted for a Democrat. It tells you the stakes in this election. Donald #Trump presents a challenge and threat fundamentally to the republic ... given how close this race is, in my view it's important to actually cast a vote for Vice President #Harris."
Chuck Darwin reshared this.
I think we should encourage Republican voters who don't want to vote for Trump to stay home. Just don't vote. At all.
I don't want them out there splitting their ticket so we get more votes for shitbirds like Ted Cruz or Gym Jordan.
Today is the Day of Remembrance of the Victims of the Leningrad Siege.
On September 8, German troops closed the blockade ring around Leningrad.
Over the course of 872 days, between 600,000 and 1.5 million people died in the city from hunger and cold.
Wbrew wszelkiemu prawdopodobieństwu, 32-bitowe #time_t bywa pomocne.
I tak na przykład wczoraj znalazłem ciekawy błąd w bibliotece #Moto. Biblioteka przekazywała do botocore datę w formie zbliżonej do ISO-8601, ale bez separatorów, np. "20240907201715" — lecz botocore oczekiwało albo numerycznego znacznika czasu w stylu uniksowym, albo bardziej standardowego formatowania daty. Tak więc te połączone cyfry były błędnie interpretowane jako uniksowy znacznik czasu, co dawało rok 643378.
Podejrzewam, że gdyby nie to, że 32-bitowe time_t sypie się na tak wielkich znacznikach, to pewnie jeszcze długi czas nikt nie zauważyłby, że daty są błędnie interpretowane.
github.com/getmoto/moto/pull/8…
#Gentoo #Python #32bit #przenośność
Against all odds, #32bit #time_t is sometimes helpful.
For example, yesterday I've found an interesting bug in the #Moto library. It was passing to botocore a date that resembled ISO-8601, except it did not use any separators, e.g. "20240907201715" — while botocore expected either numeric UNIX timestamp, or a more typical date format. As a result, the joined digits were incorrectly interpreted as a UNIX timestamp, giving a date in the year 643378.
I suspect that if not for 32-bit time_t failing on timestamps this large, for a long time nobody would have noticed the dates being misinterpreted.
8th September, 1966 - Star Trek premieres on U.S. television.
Let's quietly forget that Trek actually premiered on Canadian TV two days earlier, eh, and wish a Happy Birthday to the Starship Enterprise and all who flew - or will fly in her...even that guy who paints the bridge.
WaPo continue shift to actual reporting on mentally unstable Trump?
Series of headlines this morning:
"Trump’s Wisconsin speech was peppered with falsehoods"
"Trump says he wants to modify 25th Amendment"
"Trump threatens legal action, jail time in rant about election ‘cheating’ "
reshared this
Chuck Darwin reshared this.
* 2014: CAS OA Policy shorturl.at/r7DEu
* 2016: launch of the preprint server ChinaXiv (one of the first in Asia)
* 2020: launch of annual OA Specialist Trainings for researchers/professionals across the country
* 2022: launch of the #OpenScience Research Centre os.las.ac.cn/zh-CN
* 2023: OA platform PubScholar etc.
LA Plant Genetics
in reply to AI6YR Ben • • •It is approaching the traditional firebreaks (highways 18 & 330) and has jumped 330 at 0% containment, so it looks very bad as it begins to approach the residential neighborhoods. There should be fire roads downhill of 18, but I know it has crossed 18 in that area before. If it is not stopped near 18, it will be bad as most of the structures are uphill of there.😬
(I did a project on fire history in this area for my art class in college. It was challenging to access downhill of 18).
W6KME
in reply to LA Plant Genetics • • •AI6YR Ben
in reply to W6KME • • •BakersRelay
in reply to AI6YR Ben • • •AI6YR Ben
in reply to BakersRelay • • •BakersRelay
in reply to AI6YR Ben • • •LA Plant Genetics
in reply to BakersRelay • • •Chuck Darwin
in reply to LA Plant Genetics • • •Line Fire @ Base Line Street & Aplin Street, Highland - #LineFire
share.watchduty.org/i/33389