Lemmy: Federated Alternative to Reddit in Rust
github.com
github.com
Whether you believe them or not is up to you of course.
From your link:
Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure. Aggregate usage numbers track how popular font families are, and are published on our analytics page. We use data from Google’s web crawler to detect which websites use Google fonts. This data is published and accessible in the Google Fonts BigQuery database. To learn more about the information Google collects and how it is used and secured, see Google's Privacy Policy.
"Use of Google Fonts is unauthenticated. No cookies are sent by website visitors to the Google Fonts API. Requests to the Google Fonts API are made to resource-specific domains, such as fonts.googleapis.com or fonts.gstatic.com, so that your requests for fonts are separate from and do not contain any credentials you send to google.com while using other Google services that are authenticated, such as Gmail."
That's basically saying Font download is not being associated with any individual. And the part you quoted says they keep the aggregate stats, which is reasonable, especially given that the aggregated stats are available publicly.
Traditional tools like muting a user, silencing an instance (if they're spamming up the Federated Timeline on other instances, like Humblr.social does) and blocking (if the mods are total shit) can still be used. Small instances are the bulk of the content, so you aren't about to block them. Large instances like Mastodon.social are generally blocked tho (if your admin/democracy cares about a vibrant Fediverse).
Ah, so you achieve vibrancy by .. blocking a large number of the users?
It's not so much about "blocking" mastodon.social as not choosing to link up with it - because your instance is a specific community, and actual human social relations thrive when they can choose who they're hanging out with. So you choose to talk to other smaller, more diverse communities that you can actually get to know a good chunk of the people in them, instead of just drinking straight from the firehose that is a big instance.
Federating with another instance is basically two groups of people deciding to hang out together, effectively merging. Federating with mastodon.social means, effectively, merging your community with mastodon.social ... which means submerging it beneath the mass of mastodon.social's much greater activity.
A vibrant Mastodon isn't a more-obtuse recreation of the Twitter experience. Twitter is already Twitter. It's about fostering all the things that Twitter isn't - personal and Dunbar-scaled and locally moderated and diverse.
Also, I think Mastodon’s design deliberately steers instances away from becoming large ones; it rather tries to be a nurturer for various small communities and subcultures. It doesn’t view size as a good thing, and that’s totally okay. Nowadays, I think we need less monoculture and more diversity/creativity in our society.
Might be your particular corner of the fediverse, I prefer to have as much reach as possible.
You could have a personal (stored on device) Bayesian filter that learns from your preferences, and a shared one to block spam spotted by your contacts
As other people suggested, I don't think it should be at the node operator level, for freedom of speech concerns
Most instances will quickly shut down any spam, so it doesn't really fill the federated timeline that much. Local accounts are something you as an administrator need to act on, so they are the annoying ones.
In my experience, instances that allow spam are rare and the get quickly blacklisted by everyone from showing up in the timelines (there is luckily a neat middleground between blocking the instance entirely and not doing that; allow local users to subscribe to that instance, which is my default action for all instances that aren't hosting illegal material for me).
Good thing is that the Mastodon instance owners use shared block lists for servers that are currently used to ban free speech instances; that infrastructure could also be used to create a collectively managed list of instances that are full of spam.
Nice.
I also recently found the early but promising Plume project for operating a federated blog ( https://joinplu.me/ ).
Icing on the cake? Quite a few of the federated projects are written in Rust.
Is that any different from a regular website?
I don't read many blogs but I would assume having tags or a "more like this" that search across the fediverse could be useful?
Are those things that people have in blogs?
Leaving it to last makes me worry that it won’t happen.
Not federated yet either unfortunately. But I think one of the few fediverse projects that dogfoods ActivityPub by using the client to server protocol to communicate between frontend and api.
I get that somebody probably needed to do this work of standardization. As a project it seems to lack imagination, though. There is nothing to get excited about as far as I can see. It's just a consolidation of very familiar social media functions.
That does not seem like a feature to me, and completely breaks geteather imo, sadly. Most of the good content on reddit is older than 6 months. Imagine if reddit decided to delete posts older than 6 months, jesus, every 6 months there would be a flood of the very same questions/posts/comments...
There are other tools for recording information for posterity.
Good work!
It would also nice to have a NNTP gateway to these webforums. VBulletin had one.
(I'm also doing a Fediverse project -- MeowCat https://github.com/cabalamat/meowcat2)
What I haven't found in the docs is how federation would work.
For more general info on ActivityPub itself, see https://activitypub.rocks.
Very nice work!
So what does this do?
You could use this code to host your own Reddit (or you will be able to once they project is more developed).
Poor code reuse, same bits of code copy and pasted all over instead of being refactored out into their own methods. Methods which are doing too much different crap. The single responsibility principle is broken everywhere.
Imagine trying to write unit tests for "Perform for EditPost", this method is doing far too much and would be a pain in the ass to fully test. If you're making a method called "EditPost" it should only be doing the actual post editing, not making connections, or user validation or checking for a ban. These should happen in a method which only handles connections, or a method which is called "ValidateUser" which is properly re-used.
Generally speaking, the structure as a whole isn't very readable, poor names, methods and files which are doing too much. The project wouldn't scale well with a bigger team or if it grew in terms of codebase size.
The server.rs looks like an implementation of RPC over websockets. So a refactoring might be to model the interface using something like https://grpc.io/ or any other IDL then code generate Rust server stubs and Typescript client stubs.
Cargo has a mechanism for this. https://doc.rust-lang.org/cargo/reference/build-scripts.html
The other area where there is some boiler plate is the Diesel ORM. Diesel does generate some code ie. schema.rs but you are left to write the structs that implement these as well as Form structs for passing data to Diesel.
BUT, sometimes things to just logically belong together and having one file to find them is just easier.
It's a rediculous metric to use.
I consider IJ and most jetbrains products to be top-notch but that was a crippling experience. And I can't really say I blame them :)
EDIT: I agree with you by the way* just saying that even good tools can fail when the sizes get crazy!
It tends to mean that someone isn't following the single responsibility principle and the code is harder to understand and less maintainable. Obviously these aren't hard and fast rules but are combined with many other code smells and metrics.
For example, I really really dislike long methods with generic names. Usually this means there are too many things happening in a single method. The method name, it's input and output parameters should give the reader a fairly exact idea of what's happening in the method.
So if I wrote a method with this signature: public List<bool> ProcessData(List<string> input)
If you tried to predict what this might contain in the body, you would have zero idea.
Now this method:
public List<bool> ValidateVipCodes(List<string> input)
Just seeing this signature, you could easily imagine what the body would look like without much thought at all.
Great code should be structured in such a way that someone can view the project, ONLY LOOKING at file names and method names and have a good idea about what is going on and how it might work.
I'd love to hear a justification for this idea.
As for the frontend, it's all typed, and very minimal. Very rarely do we see frontend code that does just what it needs to do and nothing else. The fact that they achieved a "React-like" (Inferno) environment and managed to keep the frontend under 80KB is a feat.
That's not to say it's perfect, but it's not finished. I was just very surprised to be able to jump right into the code and see what was going on without wading through boilerplate.