• 0 Posts
Joined 1Y ago
Cake day: Feb 15, 2021


Imho, technology and cold mathematical algorithms is the only thing that can enforce that balance. Every attempt at putting humans at the helm ends up leading into corruption.

Capitalism is actually being regulated, but by the rich and corrupt. The banks are not doing anyone a favor, and the current judicial and tax systems are designed to favor the richest, who can afford the most expensive lawyers and have connections everywhere.

The tricky thing is finding that key algorithm that could allow us to reach that balance… and then getting it adopted (which would be even trickier). For this, FOSS p2p systems like blockchains and cryptocurrencies could be a useful tech. Even though it has a reputation of being “untrackable”, that’s actually not necessarily the case… a bitcoin address can be tracked in the public p2p ledger. A well designed cryptocurrency can actually open the door to full disclosure and transparency in the transactions of public funds so that they are publicly auditable with no way for any records to be lost “by mistake”, for example.

If you want to minimize dependence from outside servers then it’d be best to centralize, not federate. If you want a million servers with 5 people on each you need dependence with the outside servers you want content from, unless you are exclusively interested in the content those 4 other people post in your one server.

Your subscription to a community from an outside server will always depend on the outside server providing the content from that community. And you have to also depend on your server having connection with that outside server.

You necessarly need every server to depend on all outside servers you want to participate in. Either that or you’ll need to have one account in each of those servers you are interested in, which wouldn’t be that different to the end user from having each of those servers be centralized.

Personally, I feel like it makes more sense to just have each instance be its own server without hosting the other instances content and instead have the user identity/account able to access every single server that speaks the same protocol (something like OpenID to have a common user account across services). Then use standards so a common UI can be used client-side or for any particular server-to-server communication (much like how blogs can do backtracking between blog posts from different blogs and so, without them really having to federate). It would be more efficient while having the same end result but with a more free and open ecosystem, like the blogosphere used to be before it was shadowed by twitter & facebook.

To me, federation between private servers the way mastodon does it only makes sense for private communication like XMPP or Matrix… but the minute you are publicly posting content in the internet it makes no sense to have servers mirror the content from others just so people can access that content from one server in the next… if redundancy was the point then it would make more sense a P2P model, if a common UI/account was the point then separating those as independent servers would make more sense. The current structure binds each user account to one instance, the content being public forces the instances to list which other instances they allow, and this makes it so you might end up having to create multiple accounts in different servers if you wanted to access instances that do not want to federate, and at that point it’s not much different from centralized services. It restricts what instances the user can access (based on which instance they are registered with) and places extra responsibility and bandwidth/storage requirements on the instances themselves.

There’s ongoing work to encrypt much of the metadata. https://github.com/matrix-org/matrix-doc/pull/3414

Yes this is needed for room persistence across multiple servers, but IMHO that is a solution looking for a problem and also a highly over-engineered one.

Without this solution the transition to p2p would be much more complicated, would it not?

GNU/Linux is about Freedom. Among them is the freedom to choose what runs in your computer and how. So in that sense, it is about choice.

That’s preciselly what allows anyone to change anything. If anything, it’s the ones that fight against that freedom the ones with the controlling OCD.

Choice is what drives innovation and change. If people aren’t allowed to choose and can’t experiment with alternatives then they’ll always have to use the same thing, no competition, no change.

I do agree that no software should try to “ship everything”. But that has nothing to do with giving choice. The UNIX philosophy is a good example of the freedom that can come from simplicity, you don’t need a program to do it all for it to empower user choice. In fact, often the small tools that do just one thing but do it well are the ones that offer the most flexibility in the way people can integrate them in very different workflows.

Note that allowing the user to choose by themselves what they run/do is not the same thing as demanding that devs implement/give the user anything.

I’m sure I’d agree with the underlying context, but I think it picked the wrong message. Choice is good and Free Software is about choice.

That’s why I think it’s ironic how devs are the ones who want to place the blame on the user “Distro”, asking them to not theme it. It’s perfectly possible to make a Gtk app that doesn’t break with theming, just how it’s possible to make a beautiful HTML page that supports user stylesheets and doesn’t rely on modern overcomplicated layers of frameworks.

Imho, app, theme and Gtk devs need to seat and set up the semantic rules that separate what’s content from what’s style.

A Gtk app should not try to define the style, the theme should.

I get that some apps might want to differentiate themselves from the rest… but then that’s completely against the idea of having a toolkit that’s shared and that gives a consistent look. If what you want is a unique look for the app, go the Google Chrome route and build your main UI without relying on GTK theming. Or shoehorn the clusterfuck into the app, harcode it all at static compilation or with a wrapper to define the user environment if need be. It’ll be defeating the point of having a consistent toolkit… but well… if you don’t want users to have that theming freedom, don’t give it. Just don’t pretend it was the distro’s or the user’s fault that they used the theming options. Gtk themes are indeed meant for theming, not for individual apps to define their branding. They were designed to be set by the user environment.

Just a personal opinion.

But there are also a lot of “tech enthusiasts” that actually enjoy engaging in passionate discussions about what approach to desktop environment is optimal.

I’m sure the alternative of attempting to centralize and armonize it all not only will be unsuccessful at preventing conflicts (because there’s no such thing as a “one size fits all”) but it’ll make it harder for those who do want to have the freedom to experiment with alternative approaches.

I’m not convinced that you’ll attract more tech enthusiasts by trying to unify everything. Systemd in a way tried to unify and standardize things (with relative success) and it ended up resulting in just another source of discord.

I think at the end of the day, having options is good, specially for the enthusiast who actually wants to experiment with different tech. Discussions and debates about different approaches are good, just as long as they are respectful. And outside of minority groups (or extremelly loud *ssholes, which exist also outside Linux), I haven’t noticed any more toxicity in the Linux world than I have seen in any other topic between people passionate about something they enjoy. I feel the accusation “the Linux desktop community is very toxic” is either exagerated or born out of misinterpretation.

I seriously doubt any of these are reasons for the masses. You can go and ask any average person and chances are (s)he won’t even know or care about GNOME/KDE, systemd, or actually have any idea of any kind of toxicity of this kind. I think the article exagerates the importance of some pretty irrelevant internet discussions that are only followed by those who are actually geeks that are passionate about technology, not “the masses”.

In fact, the first time I was ever exposed to toxicity in the computer world was when Microsoft, MS-DOS and Windows users continuously criticised aspects of those very same systems (the “blue screen of death” meme being a famous example of things like this later on). Not in the Linux community.

Also, the article claims there’s a lack of developers but fails to offer any numbers that can be compared. How many developers actually work on Windows (the OS, not apps) vs how many developers work on GNU/Linux OS? how many of them work in it for a living? (because there’s people who do actually get paid to work for Linux) how many don’t get paid and still contribute adding up to insane numbers of hours? I don’t think it’s that simple, you can’t throw an assertion based on a presuposition you hold on one particular aspect and forget about the rest of the picture.

I got all excited because I thought it was a new Matrix client designed to be more Discord-like (using Matrix Spaces and so). But I was disappointed when I discovered it’s implementing yet another different protocol (it’s not even federated?)…

They do have a Matrix bridge though. I do hope they come together and further work with Matrix, since I believe the Matrix protocol can do most (all?) of what they are already doing, it’d be easier to migrate discord communities to Matrix if the UI transition was as seemless as it seems to be with Revolt. Revolt could have potential to be the host of a new big Matrix instance to further move people away from depending on matrix.org central instance.

I guess if they do have an officially maintained Server-to-server bridge then it would be equivalent of it acting as a Matrix instance. And that would be great. But it’s unclear if that’s what they are doing / planning to do. The Matrix website claims to not be aware of any server-to-server bridging having been done before, which makes me think Revolt might be doing a “bridge bot” bridge (can someone confirm?), which wouldn’t be as interesting.

If done well it could also boost the local economy. A lot of money in the Software industry goes to huge multinational companies outside of the EU or residing in tax havens.

I wish one day the EU wakes up and starts building its own Google equivalent but based on Free Software. I’m afraid it won’t happen in my lifetime, though.

@FerktoPrivacy*Permananently Deleted*

What the email provider snitched is the IP address (which wasn’t “tori-fied”). So it was anonymity what was compromised in this case.

The email was openly used for activism so the police was already investigating it, they only wanted to know the identity of the physical person behind it, and that’s what ProtonMail helped with, since the activist didn’t use anonymizers. The police didn’t need to decrypt the contents of the account or compromise its privacy (which is what using ProtonMail would have protected against), just its anonymity.

@FerktoPrivacy*Permananently Deleted*

Sure, someone can have high standard for privacy and at the same time have no desire for anonymity. But what was compromised in this case is the identity of the person who owns the email. The email remains private, just not anonymous.

@FerktoPrivacy*Permananently Deleted*

Yes, Tor is another example of a “new layer” on internet routing (I2P functions the same, you can also use it to access the clearnet if you know an exit node). VPN would be fine if you could trust the provider, but imho that’s just shifting the trust to some other company, more of a patch rather than a proper solution to online anonymity.

@FerktoPrivacy*Permananently Deleted*

“Private” and “Anonymous” are different things.

You can protect privacy with encryption, and I believe ProtonMail does work for that, but trying to protect anonymity is an entirely different beast. I’m not convienced it’s possible at all in any way that’s reliable (not just email but also even simple web browsing) unless there’s a change in how routing works in the internet, or a new layer is developed (like I2P, but even that’s not really a warranty).

They should have done it for Minetest, Terasology or any open source Minecraft alternative so their work can truly serve the community.

But it’s not that easy. Having a “discussion around whether abuses occur” implies allowing being apologetic towards those acts which might be abusive.

I’m sure fascists don’t think of fascism as abusive, even if it is. Would you allow discussing that?

At some point you need to set a clear dogmatic/axiomatic definition of what’s not allowed (with examples from different geopolitical positions) and don’t allow anyone to put that in doubt, abiding by that definition should be part of the rules.

Of course this makes it much harder to discuss things openly, but that’s the price to pay if you want to have a rule that claims zero tolerance.

To be honest, I’m not a big fan of Twitter-like services (I find there’s way too much noise in such feeds), so I never really explored the Fediverse surrounding activitypub too much. Any criticism I have on Lemmy current structure is likely to extend to other parts of the Fediverse where similar approaches apply. So I guess you could see my points as rants on that approach for public cross-publishing in general, rather than Lemmy in particular. I guess I picked the target I feel the most interest towards and that I think has the most potential to become something I could use a lot.

If Mastodon (and the activitypub fediverse in general) has the same approach of cross-publishing and forces instances to serve the content from third parties, I think it’s risky that they don’t have a stronger policy towards whitelisting that imposes a tight control over what instances are allowed to have their content served through them, imho it’s asking for trouble to appear. So I think whitelisting was a justified approach in case of lemmy.

In my mind, the issue with whitelisting/blocklisting is the limitation on the reach of the federation. People would have to create multiple accounts to access networks that don’t federate, rather than using one account that can access it all. It makes sense for an internet forum to ban users, block them. But it would make no sense for an internet forum to explicitly block their (legit) users from visiting other forums.

So, ideally, it would be best to find a solution that allows users to access any instance that’s technically compliant with the protocol without having to impose the burden on each instance host to carry responsibility for the content of other instances.

So you claim there should be a separate service for each community-independent feature : one for providing ID, maybe one for DM, one for sharing blocklists, … That is indeed another way to do it, I don’t think I ever claimed federated user instances was the only one. It is still one way, and it has its own disadvantages but also advantages over the one you advocate for.

Yes. That’s the gist of it. I feel we are reaching an understanding, I’m hoping our comments will start getting smaller :P (although I do enjoy the conversation).

Also note: imho, there’s a big difference between serving content through federation for 1-on-1 private communication that can be encrypted end-to-end where not even the server knows what data is being exchanged, and hosting public content for everyone to see. I suspect this is why XMPP / Matrix can more easily federate openly without leaning towards whitelisting. This is why I’m not so worried about 1-on-1 conversations. In fact, just use XMPP/Matrix (or even email!) for private communication, no need to reinvent the wheel. The user-instance could even just be an XMPP/Matrix server and make use of their pubsub layer for the notifications on new replies.

what I mostly meant was that if you want to check an updated community feed, the community instance is aware you do that request

This is true, but there can be ways to mitigate that too. If the community is public, the API to retrieve the community feed doesn’t need to be authenticated, you might only need to authenticate the request if you want to submit content or if the community is private. And in both of those cases, even if there was an intermediary, I expect there should be a way for the original instance that hosts the community to make sure the user has the rights to do that operation on their instance, so they would have to know either way.

They still can know your IP, but that’s a different level and using the same IP doesn’t mean you are the same person. Specially when using shared computers or moving around. And you’d still have that issue if you host your own user instance to cache your accessed content.

Personally I don’t have a problem with the community-instance knowing I’m accessing the content, specially if that’s the cost of mitigating whitelisting. After all, the whole internet works this way already.

My motivation for federation is in the decentralized and open nature of it. I’m ok with having data (as well as knowledge of me accessing that data) across smaller servers, because as long as they are small and I don’t use them primarily, they won’t be able to know what I do outside of their domain, only what I do when accessing that server. The issue is when not only there’s one predominant server hosting most of the content, but also there’s whitelisting that makes federating with it and self-hosting troublesome.

Not having an account is still an advantage though

That depends on what you compare it with. The 3 points you enumerate can be done without needing communities to federate among themselves.

Note that in this section of the conversation we are not comparing “closed walled gardens” vs “federation”. The point we were discussing in this branch of the conversation was: would it be bad if one instance (ie. lemmy.ml… or gmail.com for email) is central to a substantial majority of the activity?

When I said “embrace the centralization”, I didn’t mean making it a walled garden, I meant replacing the federation between communities with shared services. With user accounts being shared it wouldn’t be any more of a closed network than it already is (it might actually be less closed if it leads to removing whitelisting). I’d mean communities will be accepted as a centralized aspect that lives in one instance, even if other aspects (like user accounts) are decentralized. Essentially this would remove pressure from the community instance to have to serve third party content since that’s the requirement for federation. And with that pressure removed, I think there’s much less of a reason to do whitelisting (the only reason left would be avoiding toxic users, but that can be done in other ways as discussed, or at the very least the whitelisting could be limited to content submission rather than content access, so you don’t need to create different accounts for accessing different networks that don’t connect with each other).

The alternative to “embracing the centralization” is actually pushing for decentralization. Trying to fight the social snowball effect that might make big instances more attractive to use than small ones and implementing more cross-instance ways to access the content so that the system is more decentralized. Attempt to minimize the impact of a community “belonging” to one instance, so that smaller communities in smaller instances can compete for user attention in fairer conditions.

So you say that as soon as you create an instance, everyone can see its frontpage, and that there is no way to create an instance where the only thing that outsiders can access is your profile?

Yes, essentially. It’s too much of a problem having to publicly host content from other people’s instances that you might have not much control on, unless you activelly monitor them constantly, which is why I think it makes sense lemmy instances use whitelisting. Even if whitelisting is an obstacle in federation.

However, you cannot do what you proposed to solve the same problem when it happens in community instances. As long as community instances federate, whitelisting is the safest option. This is why I propose they should rather not federate among themselves.

What other difference are there?

Between whitelisting vs blocklisting? I’m not sure if there are any other significant differences than what we already discussed.

In fact, do you know what happens when a user from an instance that I don’t federate with comments a post that I see? Is it simply hidden?

As far as I understand, instances are unaware of what instances not in the whitelist might have commented, because they do not host that content. In the words of a lemmy dev: " your instance may not show posts or comments in a remote community if the author’s instance is blocked. Votes are also not counted from blocked instances " …I expect this means the comment will simply not appear at all, but I haven’t tested.

We said already several times, federation also offers the advantage of being able to delegate filtering tasks to the instance you register on. Each user doesn’t have to allow/block each (community-)instance by themselves, but can leave that to an instance admin that they trust.

And I already answered that this can be done with shared blocklists. Anything you want to share, see if it can be made made independent, instead of assuming cross-instance federation is the only way.

It also allows the instance to store its users’ history (or outbox in activitypub language).

Can’t the feed just reference to community content hosted in community servers without having to host the content itself? The client may load that content in the feed requesting it from the community servers directly, without it having to be cached in the user-instance.

Or, alternatively, request separately the history feed for each community instance the user has interacted with within the given timeframe (the user instance should know which ones) and merge their history client side.

If the content is served to you by your user instance, it also means to don’t have to communicate with the community-instance every time you want to read content from it. This means that the community-instance cannot track your (passive) activity, which I think is also valuable.

You can already do that client-side. The client can cache all the requests on local storage so it doesn’t request the same data every time it wants to read it. This actually was suggested by one of the lemmy devs before.

Again, you can completely leave it in the sense you mentioned by registering on an instance that doesn’t (plan to) federate with it.

The network will be significantly crippled though, since most active communities are on lemmy.ml.

Would you say “you don’t leave gmail if you can still consume content from it”?

If gmail has a significant majority of the network of email and you still have the need to communicate primarily with gmail accounts, then yeah, you still depend on gmail, even if it’s not who hosts your email account. This gives a lot of power to gmail over the email protocol, even if you don’t have a google account, your emails will get into google’s hands.

Imho, one of the points for federation is trying to avoid depending on big central nodes. If one node is down, disappears or becomes “evil”, the impact is not as big as long as the federated network is well balanced.

If it’s about the fact that it uses whitelisting instead of blacklisting, I already told you that I’m also in favor of the latter.

I don’t like whitelisting either, but if I opened my own instance with the current state of things, I would actually apply whitelisting on my server myself to limit what I federate with.

The problem is that the way the federation works in Lemmy would force my instance to cache and publicly serve content from any server it federates with. And I don’t want to host illegal content and get in trouble.

So the issue is that whitelisting is the only way to safely host a lemmy instance without requiring close eye maintenance. This is what I see as the biggest problem.

the only difference is that the other instance’s owner needs to press “ok” before federating.

If it’s that simple, the whitelisting would not be very useful to protect against bad instances. It’ll either be inefficient (if not enough control is applied) or be a burden (if too much control is applied). The line that divides those two is diffuse and it’s likely we’ll get both false negatives and false positives, so there’ll be mistakes either way, ending up both being a burden and inefficient.

It also complicates things to add a human factor to the process of setting up your instance. You’ll have to do some public relations with the other instances and the other instances might want to keep an eye on your instance which adds to the maintenance burden, specially if lemmy ever becomes popular and it ever reaches numbers in the hundreds of instances.

With an email server or an XMPP server, self-hosting is enough to communicate with everyone. But with lemmy I’ll have to do work for every instance, at that point why not just create an account in that instance, which might actually be instantaneous. I’d rather make a multi-account client that abstracts my identities as if they were one instead of hosting my own server to have control of my identity.

I define the user-instance as a server where the user has an account, and who federates with the appropriate community-instances so as to serve their content to the user.

It would defeat the whole point if I meant for the user management instance to federate with instances of its own class. This whole branch on the conversation thread was about me wanting to explore the idea of federation not being needed to do what Lemmy is doing right now, that instead of federating you can separate the services in a more “microservice”-ish like model (but not as extreme), making it not only simpler but also more modular and reusable.

I noticed later that by “managing a user account” you probably only meant “provide an ID who allows to avoid setting up a new password”. Is that right?

Yes, more or less. It’d act as an authentication server (I explicitly linked OpenID’s wikipedia page right after mentioning “user account management”) and it’d also allow users and its sessions to be created/removed/edited (again, that’s what “managing” means when we talk data). Any operation that related to the user and not the content. It does not view/add/remove/edit (manage) any kind of community content, that would be content management, not user management.

This means that you don’t have a cross-instance profile anywhere on the internet, and need to manually connect to any instance where you have an account each time you connect on a new machine. Right?

Not necessarily, there could be user metadata stored in the user service. Things like name, profile, personal website… but also what instances the user has a token with. I expect the token exchanged is long lasting so the user-instance needs to keep track on its side about this already anyway. Much in the same way as how Paypal keeps “authorizations” for websites the user has allowed payment to be automatic, the user-instance would allow the client to know of those websites and be able to access them with the token without manually having to connect (done from whatever the client is, without serving the content). Also the notifications system could be part of that instance, or it could be its own separate service entirely.

That’s the kind of instance I’d be happy to self-host, because it’ll be mainly personal data related to my user. I’m not so interested in hosting communities.

Now it seems to me that you not wanting user-instances […] is one of the reasons why you would invoke meta-communities as a way to keep track of a cross-instance list of communities.

It’s the other way around. Don’t you remember what started this “federation” topic?

To me cross-instance “topics” (either tags or meta-communities) would be the one thing that would make federation useful. Without that, I don’t see the benefit of federation. Which is why I was talking about separating the user management (and notifications) from the content management, so that you can achieve shared accounts without having to federate.

Sorry if I’m repeating myself (I think I’ve said that same paragraph in almost every comment, with different words) but I don’t know how else to explain it.

Unless some instances federate only with lemmy.ml, one is never incentivized to stay on lemmy.ml if they want to leave it.

Again: “You are not leaving lemmy.ml if you are still consuming its content.”

If you are using the non-transitive property to consume lemmy.ml content, then you are not leaving lemmy.ml, even if you are connecting to it through a different instance. Even if you don’t have an account in lemmy.ml, you did not really left it. Since we don’t have a cross-instance “topic” to subscribe to, and since you don’t want “duplicated” communities, you have to keep relying on lemmy.ml as the central node where most of the active communities are.

I’m not sure about why stopping to interact with the biggest instance would become a goal per se.

It doesn’t have to be a goal.

But in that case just embrace the centralization of those communities, what’s the advantage of federating? The things you want to share cross instance, share them by having a separate service handle them. Only if there’s a reason to have community-servers directly communicate with each other (eg. cross-instance “topics”) does federating across them become useful, imho.