One suggestion: if you want the federated crowd to jump on board, then choose another font provider than Google, which uses their font links for tracking.
Thanks for pointing this out. I guess this is something I had assumed Google does by serving the fonts for free, but I never really bothered to look into it. Going to remove all Google Fonts references from my projects now.
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.
Thanks for the clarification. However I'm not sure that means they don't track. They specify some of the things that they do with the data, but the last sentence "To learn more about the information Google collects and how it is used and secured, see Google's Privacy Policy" means that they could also use any piece of data to improve their products.
Would one run into licensing issues with this? I'm honestly not sure if their usage is predicated on being served from Google, nor knowledgeable enough about the law to even guess.
As someone running a federated server (mastodon); you get more problems with local spam than with foreign spam.
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).
It doesn't look like that might scale at all. In other words, it works because Mastodon is a very small, niche community.
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.
Generally not, proactive blocking or silencing is reserved for instances that host illicit content like child porn or hate speech. Inter-moderator communication happens between your instance admin/democracy (or whatever structure your instance uses) and other instances.
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).
Honestly, I think this is the wrong way of looking at things. The Fediverse isn't really like a single social network that's shattered amongst many instances ... it's more like a bunch of individual, separate hangouts, in the vein of classic forums and IRC chatrooms and fandom websites, which have the ability to talk to each other and share stuff if they want.
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.
I think this is inherently a sociological problem than a technological one. When there are enough people in an organically grown group, the community will become unsustainable and then 1) it disintegrates into multiple groups until it becomes stable again or 2) it transforms into a hierarchial, authoritative society where a small group of people makes most of the decisions.
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.
It'll probably end up "solved" in a similar way to email span being "solved" - if global spam starts to become a problem, you'll have big blocklists of spammy instances and general suspicion towards federating with any new instance that doesn't look sufficiently trustworthy.
Malicious actors definitely try to spam and data mine the fediverse, but their accounts get disabled by the local instance admin, and when they try evading that by spinning up a few instances on their own domains to hide their spam or follow bots behind, those instances generally get blocked by instances that see said spam toots or spam followers.
Might be offset by way fewer ads, influencers and platform-driven notifications. I find that those things are the main sources of spam on say Twitter or Instragram.
Federated bayesian filters or local machine learning ?
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
It doesn't look like there's any federation right now, the test site (https://dev.lemmy.ml/) says "Federation into the ActivityPub network is on the roadmap."
I have also reddit/HN clone running on https://esourcenews.com with code on github (written in python - Flask https://github.com/matoous/newz). Although this one is not federated I added tools such as automatic RSS feed import.
I'm not convinced by ActivityPub. A lot of people seem to think that it's cool but the documentation makes it look like it's just a schema for social media applications. It might be an obvious move to try to standardize social media platforms because they all involve roughly the same kinds of user activities. Interoperability is cool, I agree. But the ActivityPub documentation has a whiff of the old XML/"semantic web" hype about it. It's verbose, unnecessarily object-oriented, and it doesn't seem to advance any kind of new or interesting vision for the architecture of these interconnected systems.
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.
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.
Follows work at least. Commenting directly on stories works, as far as I remember, but I think the main issue is that it doesn't properly create a list of inboxes that a comment is addressed to to push the messages to them.
Yup, creator of Aether here. Small difference, this is federated, Aether is decentralised. Far as I understand this is more like Mastodon where some people host servers that talk to each other. Aether is more like a decentralised Usenet, every user is a server.
Can you explain the 6 month thing to me? If I understand correctly, posts/comments older than 6 months get deleted, unless you decide to save it locally? Even if someone saves a post older than 6 months locally, others cannot see it, right?
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...
Love the processes in this aether project with the voting for mods and such. Wish there was an easy way to clone it and create a subspace aether system that was not attached to the others. I have some user groups that would use this kind of thing - but they would quickly try to game the mod voting thing in many ways, wreck all kinds of havoc trying to get things blocked / banned and ruined - and so we'd need a function for a high level set of super mods and a way to prevent the coming toxic soup from running over into the main project.
Took a look at the open source page on there and there is a bunch of stuff, it's impressive, but too complex for me to try to piece together. Perhaps something like riot matrix is more like we need, and to find some way to incorporate the mod voting kind of system as some kind of addin to a self hosted instance of matrix kind of thing.
off topic but ~20 years ago Lemmy was a beautiful,native vi clone for Windows. I wish the author had kept it going or made it open source. Vim has such an ugly GUI.
I think a project like Diaspora failed because they chose to write it in Ruby on Rails. Ruby is nice from a purist point of view. But you'd want to build something like this on top of a language which is popular, accessible, has a low learning curve and can be easily deployed anywhere.
I don't understand what this is. At first, I thought it was a scraper for links which is the only reason I go to reddit at all. Such a thing would help stop me from getting sucked into the 80% of reddit which is nothing but a smelly pile of poo.
Given the response to this, i would be interested to hear why you thought the code quality was amazing. We seem to have two people with different ideas about code quality, and perhaps we would all learn something by investigating that difference.
I was mainly commenting on the frontend as I'm not well-versed in Rust, my dissenter seems to have a problem with the backend and the organization of the project, which seems unfair since it's in it's infancy, you can always restructure a project and reorganize code. I was commenting on the code, not the files.
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.
On the contrary, I thought the code was terrible quality. If someone wrote this code at my company they would be fired, or more likely not hired in the first place.
That's a terrible, sad and rude comment that does not belong in HN. Instead of just criticize you could offer a constructive review. I hope English is not your native language and it has a less aggressive tone in the translation.
Well, for a start... having a single file called "server.rs" which is 2256 lines long is already disqualifying. This file, code structure would be incredibly poor for developer efficiency. It just grows and grows and does all the things while having a vague sounding name like "server.rs" Why is server.rs doing "EditSite." What does the name EditSite mean anyway?
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.
Depends a lot on tooling as well. If you have tools that give you effective jump-to-definition, find-usages, etc, then the file structure sort of fades away, because you jump from fragment to fragment without really worrying about what files they are in.
Small note here: it's obviously not it's an "absolute" rule that X lines of codes = fired. But for me, it's just a major code smell when people are writing very large single files with generalized names like "server.rs" or "processor.java."
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.
There are a few opportunities for code generation here.
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.
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.
