Vänstermedier deltar i oseriös hets. Borgarmedia, högertroll, högerpolitiker, nazister, högerextremister, borgerliga ledarskribenter med flera hetsar på bred front mot vänstern. Vänsterpartiet och många vänsterpartister.
happy 10th birthday, ActivityPub! 🎉🎉
cross-posted from: hexbear.net/post/3384817
link that was attached to original post (1st ever ActivityPub), original post is linked in this post
The obvious choice for ActivityPub’s birthday would be the 23rd of January 2018 - the day it was annointed as a W3C recommendation. That doesn’t seem quite right though - its not as if the spec came into existence in any sense upon that date. In fact, Mastodon implemented it before thne.There are several possible dates you might pick, but for me it will always be September 5th 2014 - when I committed the first sketch of a specification I called ActivityPump [github.com] and pushed it to Github
It wouldn’t be until November that I actually submitted (a revised and enhanced version of) that draft to the working group, but even then I had the very nucleus of the specification written down.
Happy 10th birthday, ActivityPub. 🍰
The obvious choice for ActivityPub’s birthday would be the 23rd of January 2018 - the day it was annointed as a W3C recommendation. That doesn’t seem quite right though - its not as if the spec came into existence in any sense upon that date. In fact, Mastodon implemented it before thne.There are several possible dates you might pick, but for me it will always be September 5th 2014 - when I committed the first sketch of a specification I called ActivityPump and pushed it to Github
It wouldn’t be until November that I actually submitted (a revised and enhanced version of) that draft to the working group, but even then I had the very nucleus of the specification written down.
Happy 10th birthday, ActivityPub. 🍰
like this
melroy likes this.
Åtal för grov utpressning och grova bokföringsbrott. Åklagare vid Åklagarmyndigheten och Ekobrottsmyndigheten har väckt åtal i ett ärende som handlar om försök till grov utpressning, grov mordbrand, grovt ocker, osant intygande, olaga tvång, grov utpressning, övergrepp i rättssak, folkbokföringsbrott och grova bokföringsbrott.
Fediversum i Sverige - Svenssons Nyheter
GE-Proton9-13 Released
Hotfix:
- Update vkd3d-proton to latest git to include World of Warcraft MSAA fix
proton:
- wine updated to latest bleeding edge
- dxvk updated to latest git
-proton upstream fixes added
Additional:
- protonfixes updated to latest git
Instead of algorithms why don't we create a map of Lemmy?
cross-posted from: lemmy.dbzer0.com/post/27216373
Instead of focusing of creating good algorithms to push certain content to users why don't we focus on creating a good map that allows users to find the kind of content they want more easily?I found this website that created a map of reddit with different countries for different topics and I thought it would translate to lemmy because instances sort of do this already really well.
like this
themadcodger, MyTurtleSwimsUpsideDown and KaRunChiy like this.
The map up above checks how similar two subreddits are by checking how much overlap the people that comment in both communities there is. It could be the same as that or maybe something different.
The easiest would be to have countries similar to how it had in the map of reddit be the instances and show the connections between subscribers maybe.
I know I was talking about how the map I linked to worked which is based on reddit.
So maybe like some sort of list of computer instructions -- which tells the computer to generate a map, and then tabulates the data and presents it to the user like...
If only we had a term for this...
Like algoism, or arithmos... something to do with calculation or something...
I never said we shouldn't use algorithms I just think what those algorithms were doing could be different.
People say they have problems with discoverability. A map will help people find the content they want faster.
like this
astrsk likes this.
like this
astrsk likes this.
I think its a cool idea. I had a similar idea once: fungiverse.wordpress.com/2024/… but for the whole social web instead of just Lemmy.
Its interesting, it could get overwhelming easily though. Maybe this could be solved by only showing instances of a certain size?
NASA discovers Earth's electrical field at last after 60-year search
A long-sought invisible force wrapped around Earth has been detected more than half a century after it was first hypothesized.
The field, dubbed the "polar wind," explains how Earth's atmosphere escapes easily and rapidly above the north and south poles, and may have played a role in shaping our planet's thin upper atmosphere.
Edit: ELECTRICAL field sorry
A long-sought invisible force wrapped around Earth has been detected more than half a century after it was first hypothesized.
99% chance I'm being an idiot here, but, compass?
"The discussion continued for quite a while without making much headway."
I think Debian is interesting, being such a large project of collaboration. I want this democratic, volunteer, non-corporate backed, free project to show that 10000 eyes make bugs shallow. I wish this model produced new ways of doing things, bringing people together in the spirit of creativity and playful productivity.
I've used Debian in different ways for around 15 years now, and I really want it to succeed.
Having said that, there is a "but..." looming in the back of my mind. But... it's difficult to ignore that other distributions are the ones pushing Linux forward. The innovation from Fedora and the distributions still called OpenSuse explore new areas which become the standards.
This is not criticism of Debian, I just wonder if we humans are capable of collaborating freely at that level without some top-down force directing work forward, or if we are bound to being one step behind, always trying to catch up to what others have already done?
I'm glad to see were rediscovering what we lost in 2002 when we laid off all our mentors and experts after y2k.
Reproducible builds require complete and consistent validation. The deb format lacks this ability.
BrowserPub: A browser for debugging ActivityPub and the ⁂fediverse
👀 BrowserPub: A browser for exploring #ActivityPub and the ⁂fediverseBrowserPub · A browser for debugging ActivityPub and the fediverse
Explore the open social web through the lens of ActivityPub and the fediverse.browser.pub
Help a noob with jellyfin on Ubuntu server
I'm have some trouble on how to get Jellyfin running on Ubuntu server. I'm Very new to using Linux with the command line so please be patient with me.
i have tried to Duck(duckgo) a solution but i cant find anything that works for me.
If you need some kind of logs please tell me how to get them!
// A very lost linux noob
like this
Oofnik likes this.
How did you install jellyfin?
It should not core-dump (read: hard crash, something has gone terribly wrong), at best you should get a configuration error and errors like that.
You can see the logs of any systemd service/unit with this: journalctl -u <name of sevice> so in this case journalctl -u jellyfin (Tip: add -f to follow the output of a running service - useful for monitoring).
Note that some programs log to their own files (and not to stdout) so if the above command comes out empty you should look into /var/log/ directory.
I'm guessing you installed from Flatpak and it doesn't have the permissions to touch what it needs to outside of the sandbox.
Install plainly, or run a container with the proper permissions.
I haven't run Jellyfin outside of docker in ages, but looks like you have at least one set of conflicting tags in your exec section of that service file you posted (web something or other I can't see on mobile once starting this reply - you have a flat setting it and a flag disabling it).
Edit - also do you actually have something set for that list of variables in your exec?
I see other commenters saying you should use docker. And I agree. If you are set on doing this without learning docker, feel free to ignore this comment.
Otherwise, I would argue that learning docker and docker compose is a good investment for your linux learning. The TL;DR of docker is that it is a way to run software like jellyfin, which is prone to issues like you are currently seeing when running on "bare metal" (here defined as simply: not running in docker), in an environment created specifically for that software.
Docker makes it so other (usually really knowledgeable) people can set up a server that runs some software properly. It has all the files in the right place, any recurring jobs happening, all the permissions set up, etc. And then, they create a snapshot of that server and put it in a docker image. That image is publicly distributed and others (like you and me) can take that image to start a container. The terms are not super intuitive. But an image can be thought of as a "snapshot" of a specific computer at a specific time; it is usually set up to run a specific task. And a container is an actually running instance built off one of those snapshots.
To tie this into your use case, the idea is that you use docker to take a popular and robust jellyfin image and use docker to create a container that's running jellyfin smooth as silk for you to use. Docker is popular amongst the self-hosting community because containers don't tend to run into issues like you see above. Docker and/or the image itself control what environment variables they receive, what other software might be running with them, and a whole host of other headaches that come with running the service "bare metal."
Some comments mention Docker Compose. This can be thought of as an extension to docker functionality. To run a container in docker, you'll run a command like docker run -d <a whole goddamn host of arguments> lscr.io/linuxserver/jellyfin:latest where lscr.io/linuxserver/jellyfin is the image you want to use and latest is the tag (which is essentially the image's version except that some tags, like latest, change what they point to). This is totally fine and will work. But it's hard to make updates. The "whole goddamn host of arguments" will have important information about how your host server interacts with the container. It'll specify things like what ports from your host are forwarded to the container, what files from within the container persist after it has been stopped, and what environment variables the container runs with. With "base" docker, you need to run a command like this to bring up a container, which can get hugely cumbersome if you'rr maintaining a lot of services in containers or are trying to experiment with different container arguments. Docker Compose is a way to specify containers you want to bring up in a YAML file so that you don't need to type out or remember each service's command every time. I would strongly recommend using Docker Compose as well.
So, I'd recommend taking the time to install Docker and Docker Compose. And then the little extra learning curve to use them to run jellyfin in a container. It will take more time now, but save you time in the long run. You will know you have installed docker and docker compose correctly if you can run the command docker --version and see your version information and docker compose version and similarly see version information.
Appendix:
- Install Docker - I believe this installation comes with compose too, but it's been a while.
- LSCR Jellyfin Image - I would recommend this image over the official jellyfin one; it's easier to set up. It's the one I use.
My last note: we all started as noobs. I give this advice because it is the advice I would give my earlier self. I believe that the time investment in this now will save you a lot of pain both in avoiding the debugging now and in avoiding this debugging in future. Please feel free to reach out if you have questions.
For possibly more information on why the core is dumping (lol) try running jellyfin from the cli (probably just typing the path to the jellyfin executable and pressing enter)
If nothing interesting is printed, try adding strace before the jellyfin executable (Google strace, it intercepts all system calls and logs them) if that doesn't work tell strace to follow forks.
Other than that you could start using binary debugging tools to see what shared libraries jellyfin is looking for? Maybe run it in gdb...
What the fuck is up with all these docker comments?
Check your binaries, might not be the right ones for your platform/ubuntu version
I need to see the logs in order to help you.
I personally moved to containers as they are easier to maintain and update
We're going to need to know as a minimum:
- Linux distribution and version
- Jellyfin install method and version
- what you have already tried- not sure where all those flags are coming from
I would also support the comments here recommending that you use docker. There's only a small number of Linux distributions and versions where a distribution package installation of jellyfin is fully supported, but even then what you need to do varies across each one. All Linux distributions and versions support docker and the process is essentially the same for all of them.
New Version of Power Profiles Daemon Improves AMD Support
For those unfamiliar with it, power-profiles-daemon is a low-level component to provide power handling over DBus. Ever used the Power Mode options in the Quick Settings menu in GNOME Shell? Those options interface through this.
From 0.22 Release Notes:
Since this release power-profiles-daemon is also battery-level aware and some drivers use this value to be smarter at tuning their optimizations. In particular both the AMD panel power action now uses a progressive approach, changing the the ABM based on the battery percentage.AMD p-state received various features and improvements:
- it supports core performance boost when not in power-saver mode.
- uses minimum frequency to lowest non-linear frequency
- it is more impervious to faulty firmware and kernel bugs
This should be included in the upcoming Ubuntu 24.10 release.
New Version of Power Profiles Daemon Improves AMD Support
A new version of the Power Profiles Daemon is out, bringing a number of improvements to improve power efficiency on Linux desktops, particularly on AMD devices. For those unfamiliar with it, power-...Joey Sneddon (OMG! Ubuntu!)
like this
massive_bereavement and KaRunChiy like this.
Newgrounds is considering adding activitypub support but is concerned about hosting fees for serving images to millions of people
Original link newgrounds.com/bbs/topic/15375…
The creator of Newgrounds has considered adding ActivityPub support to join the fediverse but is worried it would make their hosting fees untenable by “serving files to millions of people on third party apps“. Can anyone with more knowledge on how this works help them?newgrounds.com/bbs/topic/15375…
Having Newgrounds on the Fediverse would be incredible. Newgrounds has a huge art community, many features not available on any platform and has been around the longest (1999)
CC @dansup @Gargron @ruud
Any arguments against separating identity from instance/platform? (single identity across the fediverse)
I am sure it was discussed here before, but I can't find a good way to search this community.
Are there any arguments against having a user's identity federate, and be compatible across platforms?
For example, let us say I sign up with my instance, matcha_addict@lemy.lol
But what if I go on mastodon, and I want to have my own micro blog. Or maybe go to write freely and post some blog posts. I'd have to make a different account on each one.
What if mastodon or write freely could just let me log in with my lemmy account (or lets call it federated account). This has several benefits:
- users don't have to scratch their head on if I am the same person or not across these platforms
- theoretically, someone following my feed can get updates on what I do on multiple platforms
Now I understand this would be difficult to implement and iron out all the edge cases, but am I missing anything on why it wouldn't be a desirable feature, given it is implemented?
like this
KaRunChiy likes this.
I agree, but reliance on an instance is already a big issue.
Theoretically, if this gets implemented, it could be possible to federate the ability to sign up elsewhere, or at least make your user downloadable and sign up with it elsewhere
This is a controversial issue.
Some people don't care about having an unique identity and actually favor creating multiple accounts on each service, to present themselves with different avatars depending on who they are interacting with. They are not "attached" to their identities and see this an opportunity to stay pseudonymous online and protect their "real" identity.
Some people think that the instance you join should be also somewhat indicative of your tribe and that they should be able to filter out who they talk about by checking the domain. This view is especially favored by the Mastodon crowd.
And then some other people (I think I would include myself) would like to be able to not just "use" a single identity, but to have portable identity in the Fediverse as a way to ensure that we can remain sovereign over our online presence. I would personally love for Communick customers to be able to use their personal domain, because that would mean that if even if I closed down things tomorrow, they would be able to migrate easily and without depending on me.
Some [...] favor creating multiple accounts on each service
That's fine, this feature wouldn't prevent them!
What you mentioned in your last paragraph is in line with what I want, but maybe more of a next step from there.
So far, the only Fediverse project that lets users with different domains (and identities) under the same server is Takahe, but its development is a bit stalled and it is only supporting Mastodon.
Are you asking all these questions out of mere curiosity or are you willing to commit some type of effort and/or resources to see this happening?
It will be yes! Right now I only have it locally and its messy, but the idea is like this:
- Your home feed allows customizing the sorting algorithm. There's a sensible chronological-based algorithm, but you can customize it more.
- Content is organized into feeds.
- By default, you have your own personal feed similar to a micro blogging platform.
- but you have the ability to have multiple feeds. For example, maybe you're into both technology and wood working, but not all followers are interested in both. So you have separate feeds, and users can follow one or the other.
- A feed isn't only for one person's posts. For example, I might maintain a woodworking feed, but I'd "share" posts from other wood workers. In essence, I am a sort of "content curator". I pick out the good woodworking content and put it in a single feed for you to follow!
- A feed can be like a Lemmy community or a Facebook Group. So it can allow multiple posters, it can be open to anyone to post, or it can be approval-only (but submitted from anyone). It can also be private or public (though that's a low priority feature)
- A feed can use another feed as a source / baseline. This might mean that you get all the other feed's posts, but maybe you as the maintainer filter it further, or add some of your own. Or you can use multiple feeds as the source, so maybe there are multiple good wood working feeds and I like them all, so I combine them
In my opinion, this replaces automated algorithms with manual curation. It also replaces moderation, as you might like a community but wish it was differently moderated, there might be another feed that sources the first feed but with extra moderation!
The project is still in its infancy and I don't get too much time to work on it. But since you're interested, I'll try to get it into an open source-able state (albeit far from workable) and let you know when I do!
I might have good news for you: you don't need to drop ActivityPub to do that. Maybe what you are looking for is very close to my idea of a social web browser, i.e, an ActivityPub-based application that is controlled by the client and not the server.
What programming language are you working on?
At a more abstract level, inviting a bunch of people to play a game, and then changing the rules of the game, is a shitty thing to do.
The fediverse has rules built into it. It has a way that it works. Changing that makes it something else.
Identity belonging to an instance, changing to identity belonging to the fediverse as a whole.
Identities containing @instance format.
Identities being federated.
This is an implementation detail, it's not required by any part whatsoever of the activitypub protocol.
All that AP cares about is that actors have an URL for their inboxes and outboxes. You can have even servers to serve your actor id from a different domain in your instances.
Hell, you can even have no "instance" at all. You can have just a bunch of static files to serve your webfinger queries and bio and even the outbox, regardless of the username that you have.
I think it's fine to have people trying to use a simplified mental model to understand new concepts. But it becomes a problem when people start taking these mental models and try to justify their opinions on incomplete abstractions.
And web browsers were only meant to be a language for formatting documents, yet software engineers realized it could do a lot more than that.
It's not just because someone design things one way that automatically all other use cases become invalid. This argument makes no sense.
That's going to be a problem whatever solution you come up with, because of the federated nature of the lemmy system.
There's no central authority to hand out usernames, so if two people sign up to different instances with the same username, any design which didn't attach instance name to each username would fail. The only way around it would be for each instance to contact every other instance which exists, including the ones which haven't federated yet, and negotiate ownership of the new username, and that's just not possible
I already talked about why that matters in my post (didn't mention anything about a person's importance), but I'm happy to clarify and expand on it!
To summarize again, this would allow users to follow a person across platforms. Part of the benefit of the fediverse is I can choose to get content from a microblogging platform as well as macro blogging or threaded like lemmy. It would be a good feature for me to be able to follow someone across all federated platforms without having to scavenge for them.
Moreover, it would allow me to use other types of platforms without having to sign up on each one. This would also be useful for instance admins. If instance A trusts instance B, then it can allow instance B users to sign in without having to sign up separately.
This could also mean that instance A could be an identity provider only
It will be difficult to implement and pretty much at the end of the list for the software you want to implement.
Users most of the time dont want to get identified ( some are here because of the privacy ) and if you want to get identified you can just use PGP signing.
It is a matter of responsibility. If you can log into any lemmy instance or mastodon server with the same account, then which server takes responsibility for your actions in the fediverse?
I have seen instances be defederate from because of their lax account creation requirements, or because of harrasment from users from a specific instance.
If an account can log into any instance, then who is responsible for banning the account?
It is a matter of responsibility. If you can log into any lemmy instance or mastodon server with the same account, then which server takes responsibility for your actions in the fediverse?
This is a good point and I should clarify: in this model, you wouldn't get open access to any instance. The instance has to explicitly trust (white list) instances from which it will accept log ins. It would be like federation is done today, but the lists would be separate ideally.
Another model is it could do it on a case-by-case basis on the user level instead of instance level. But it would still enable the user to keep their dame ID and original domain.
I don't see any technical limitations preventing that. And I think it's a desirable feature. Imagine a world where you don't have to come up with lots of passwords and sign up on dozens of websites, but instead have one identity that's saved in your device and you can access any free software service without signing up and it'll already tell you if your friends are there. It could interconnect content and features...
It's a bit difficult to get it right, though. The identities need to be secure and reliable. Servers can't vanish (or data needs to be distributed) or people will lose everything at once. We need pseudonymous handles, sock puppets and access control. And there is a lot of trust involved. We need to mitigate for spam and trolls...
And agree on one standard that gets everything right for any arbitrary use-case.
We host instances for trans and gender diverse folk, to provide a space that explicitly puts their safety first.
Take away the idea of an instance as a community/identity/distinct space, and the goal for these places existing is gone. Instead of a community and a safe space, we become a generic bit of hardware that enables transphobes as much as trans folk.
That's not something I'd be keen to keep sinking my own funds in to to support.
What I'd much rather see is instance based accounts, however, with the ability to take over/migrate them from other instances, so that if an instance goes down, people can still keep their identity. It would also allow instances focused on protecting minority communities to keep doing that.
This is a very valid concern and I should clarify a bit about the mechanism I have in mind.
An instance admin can decide which instances it federates identities with, similar to how regular federation is done (but maybe these would have separate lists)
So, in your case, you would only federate identity with instances you trust to have done proper vetting. It wouldn't be by default that having a federated instance means you have access to login the entire fediverse.
the ability to take over/migrate them from other instances, so that if an instance goes down, people can still keep their identity
I can definitely see user migration from one ActivityPub server to another being a possibility, but I really don't see how that can happen if one of the servers is down. That's too late then. If you could migrate a user from a server that is down, what prevents you from migrating a user from a server that is still up and doesn't want to do the migration? You could just pretend that it is down and do the migration anyway? I have no idea how that would work.
The proposal I saw was basically a way of "signing" your posts, and then when they federate somewhere else, you can create an account on another instance and "claim" the posts that have federated there as yours, with your private key.
Obviously, you couldn't access posts that never federated to the instance in the first place, but even with some lost content, it would let you edit, and post new content.
And as I understood this proposal, basically, you could have multiple active accounts, all of which are "you", and allow you to control your content with the same permissions.
Yea that could in theory be possible - the big problem is that it requires people to hold their own private key and manage that, both securely and conveniently. And well... tbh I just don't see that happening. If you need to keep your own private key and also keep your own password, I really don't see any non-techie people ever using the fediverse.
There's also the issue that if that private key is leaked, there is no going back. Your identity is stolen and you can do nothing to take it back. This is different from if your password gets leaked - in that case, an admin could in principle step in and reset your password and you could regain control of your account. This happens all the time when people's Facebook accounts get "hacked". They report it to Facebook and get their account back. This is impossible if it relies on a user-held private key.
It's a neat technical solution that unfortunately forgets the human, as is often the case.
What I’d much rather see is instance based accounts, however, with the ability to take over/migrate them from other instances, so that if an instance goes down, people can still keep their identity. It would also allow instances focused on protecting minority communities to keep doing that.
This exists right now. It has existed for longer than Mastodon, much less Lemmy.
Established by Mike Macgirvin in 2011 when he invented nomadic identity. First implemented in his Zot protocol from 2012 and a Friendica fork named Red, later Red Matrix, known as Hubzilla since 2015. Also available on (streams).
Not just a vague concept or an experiment, but daily-driven on stable servers since over a decade.
Nomadic identity goes even further than migration. Nomadic identity allows you to have the same Fediverse identity with everything in it (name, posts, connections, settings, files etc. etc. pp.) on multiple servers simultaneously. Not dumb copies. Bidirectional, near-real-time, live, hot backups. Whatever happens on one instance of a channel will be sync'd to all others almost immediately.
One of the clones goes down, doesn't matter. The main instance goes down, doesn't matter, you can use the clones just the same. The main instances goes down and stays down, doesn't matter, you make one of the clones your new main instance. All your nomadic connections are automagically changed to your new identity based on your new main instance. Yes, even on remote servers.
Even migration is based on the same concept. If you move from one server to another, first a clone is created, then the clone is declared the new main instance, thus demoting the original instance to clone, then the old original instance is deleted and the account with it. Not only can you move with absolutely literally everything, but you don't leave any rubbish behind on the old instance.
Only downside: It does not work on ActivityPub. Yet. It requires a special protocol, either Zot (Hubzilla) or Nomad ((streams)). ActivityPub-based projects don't even understand nomadic identity. So when you move, you have to reconnect all your non-nomadic followers.
ActivityPub implementation is being worked on, at least in theory. But the guy behind all this has, well, apparently not fully quit, but dramatically slowed down.
We'll see what comes out of this.
Mike has already implemented FEP-ef61 on (streams), and it seemed to have worked well under lab conditions. But then he rolled it out to release in July. Channels created on accounts registered after that point have decentralised IDs already. And surprisingly, it caused tons of bugs to the point of these channels not properly federating with anything. And since he's the only (streams) developer, he had to iron everything out himself. And quickly so because a few dozen people use (streams) as a daily driver.
In mid-August, he forked Forte from the streams repository. It was his vision of "the Fediverse of 2030": basically (streams), but only supporting ActivityPub anymore, with both (streams)' own Nomad and Hubzilla's Zot6 ripped out. Guess the idea was to have something with no extra protocols standing in the way of straightening FEP-ef61 and nomadic identity via ActivityPub. But this caused even more of a workload.
On August 31st, Mike sent a private post to his immediate connections (his channel is set up to send private posts by default) that said that he quits. He wanted to stop developing for the Fediverse because it got too much. The community could carry on if they want.
Trouble is, there's nobody among the few dozen (streams) users who has got what it takes, namely both the time and especially the skills to take over as a lead dev. One guy is ambitious, but he has only recently taught himself git just to make his own pre-FEP-ef61 branch for personal use. Then there are a few people who do know git, who may also know how to code, but who don't have the time.
We got one offer by a guy who wanted to rewrite (streams) from scratch. He had taken a look at the (streams) code, and he said that some of it is very old and crufty and mouldy. Of course, a lot of code probably still dates back to 2012 when Mike forked Red from Friendica to implement nomadic identity and rewrote the entire backend against Zot. Problem was, I think that guy came from Mastodon, he probably hadn't even seen Friendica in action, much less Hubzilla or even (streams), and he described himself as "thick", so we'd have to explain everything to him. Nobody even reacted.
Luckily, Mike is still Mike. He can't keep his fingers off improving the Fediverse. Every couple days, we see commits to the streams repository and/or Forte. It's just that things are moving forward very slowly now. The community is trying to figure out what and where the bugs can be by examining log files and whatnot, but nobody can track them down in the source, much less fix them and submit a PR, and that isn't talking about merging the PR.
There are very few drawbacks (assuming it's implemented in a way that doesn't break things). That's why it's part of two of the big three social protocols (Nostr & AT/BlueSky) and Activity Pub might get it soon.
I've written about and participated in discussions about implementing identities not controlled at the instance level and discussed bridges that connect activity pub to other protocols. The one major drawback people tend to bring up is moderation, but moderation is not effected like some people think it could be. Just like a PGP key doesn't force Gmail to host a user's email and a domain doesn't force Dreamhost to host a blog, even if identities are separated from instances an individual instance can still ban a user from participating in that instance or prevent other instances from interacting with your instance. The only difference is that if an instance goes down or bans a user the user can pick up and move to a different instance instead of having their account nuked. As somebody who lost a profile due to a SQL database breaking it would have been really nice to have been able to continue.
Also, in the thread here I heard a few people talking about it negating communities. We already can communicate with remote servers, I'm not fully sure where the argument that independent-from-instance-identities will break communities comes from. If something like nomadic identities are implemented, which again, they may be, your account will still be largely focused on one instance.
Say you're an arborist and join an arborist Mastodon community. You're still a part of the community, and your account is centralized there until you say otherwise. Yes, you can reply to a lemmy post or peertube post by authenticating on one of those instances, but you can already do that (there's just a lot of jank since Activity Pub's monolithic servers often have a hard time understanding each other). Yes, say you reply to a lemmy post about beekeeping that would show up in the local insatance timeline (assuming remotely authenticated posts are allowed to show up in the timeline), but again not only can you already do that, but it's not like you'd expect an aborist focused instance would have ONLY aborist focused discussions.
Lol, I hope I was coherent. I just misinterpreted a bottle of bottle of lime infused liquor as 30 proof instead of 30% ethanol so I consumed a little more than I expected. Anyway, regardless, personally consider identities separated from servers/instances a very big pro, with very little drawbacks (if implemented in a way that does not break existing implementations).
Fediverse reshared this.
Fediverse reshared this.
I don’t think a nomadic identity is the same as an instance-less identity.
It isn't. (Source: I've been using nomadic stuff since long before any of you has even heard of the Fediverse.)
Nomadic identity always requires one main instance of an "identity container" with a valid Fediverse ID. That Fediverse ID carries in it the domain name of the server on which the main instance of the "identity container" resides. You need something behind the @. The clones have the same Fediverse ID.
So if you have a Hubzilla channel on hub.foo.social, hub.bar.social and hub.baz.social, one instance of that channel has to be the main instance, and the others are the clones. If the instance of the channel on hub.foo.social is defined as the main instance, it's hub.foo.social that defines the idea (e.g. bob@hub.foo.social). From a Hubzilla POV, the clones on hub.bar.social and hub.baz.social are bob@hub.foo.social all the same.
Instance-less would require a fully decentralised, peer-to-peer approach like Briar where (ideally) each user name only exists exactly once. And with no domain name attached to it.
And peer-to-peer in social networking sounds like an awesome idea until you have to run a full-blown, fully-hardened Web server on your iPhone on a wonky 4G connection, simultaneously sending a message to and receiving hundreds of messages from hundreds of other devices out there because you've got, like, 647 connections on your friends list. And then you wonder why your phone is so hot, and the battery craps off within hours.
I hope this Join the Fediverse Wiki article can help you. I've written it myself.
It's mostly written to pick up Mastodon users who don't know much about the rest of the Fediverse, so it doesn't really explain how Hubzilla relates to Lemmy. I hope it helps anyway.
My potential argument against it starts with asking where the credentials are stored for authenticating this identity.
Currently the home instance stores the hashed password and performs authentication.
In a way, the identity “belongs to” the place that does authentication, which now happens to be the instance.
If identity is decoupled from an instance, that means authentication decouples from an instance.
If the identity “belongs to” the fediverse as a whole, then that means the fediverse as a whole has an authentication mechanism.
Unless we can come up with a distributed authentication mechanism, that means the fediverse as a whole has some authentication service, as in one, which means centralized.
This therefore breaks decentralization, unless the authentication is somehow handled in a distributed way. Maybe consensus or something on a hashed password? But if those hashed passwords are stored in a distributed manner, then you’d need a super long password to prevent rainbow table attacks on the passwords, given the hashed values would essentially be public information.
Maybe public keys are stored in a blockchain? I don’t know this is beyond me in the details.
But to summarize the problem at a data model level, an identity belongs to an instance, because the instance can authenticate them. If the identity now belongs to the whole fediverse, then the whole fediverse needs to be able to authenticate them, which if not handled correctly could lead to centralized authentication, centralized banning, censorship, reddit, etc.
Then the identity still has a home.
I’ve implemented Oauth and you still have an identity provider.
I don't understand the benefits.
users don’t have to scratch their head on if I am the same person or not across these platforms
They already don't need to worry about that. Presumably if you could log in with your Lemmy user on Mastodon, your user domain would still refer to your Lemmy instance, just as it does currently. That's besides the fact that I have no idea how this mechanism of logging into different sites would even work.
theoretically, someone following my feed can get updates on what I do on multiple platforms
They can already do that with the current mechanism. It's only a problem with Lemmy not supporting various other forms of social media concepts that prevents you from writing, say, a toot (microblog).
It sounds like what you want is just a more generic ActivityPub instance that supports more forms of social constructs.
Aside from all that, there's what other people have mentioned. Grouping users on instances has all kinds of moderation benefits.
Your last sentence is unclear, is that actually implemented?
I am trying the approach of just making multiple affiliated services, and forcing people to have consistent account names across each. See bestiver.se
Separating identity from instance was invented in 2011, first implemented in 2012, and it has been stable since 2013. Zot protocol, Red, Red Matrix, nowadays known as Hubzilla. It is called nomadic identity.
Separating identity from platform is a current WIP: Nomadic identity is to be introduced to ActivityPub and then made project-agnostic. The idea is to be able to clone your Lemmy account to Mastodon and Pixelfed and Mobilizon and Hubzilla and Funkwhale all the same. You won't be able to use all features of everywhere everywhere (go ahead, try to edit a Hubzilla wiki or article or webpage on Lemmy, haha), but it'll be the same identity. Still, it would require one account on each server on which you have an instance of your identity.
But what you're talking about is full, unlimited user write access to over tens of thousands of instances of over 100 projects. Like, visiting any one of these tens of thousands of servers and being able to do absolutely everything a locally registered user can do, no exceptions, right away.
Like it or not, but this will require a local account. Even OpenWebAuth doesn't grant you full local user write access, nor does it allow for drive-by, on-the-spot creation of full-blown local user accounts on any instance, regardless of registration of local user accounts is allowed or not. Like, you can't just visit hub.netzgemeinde.eu and, within a split-second, have a local user account with the same login credentials as on lemy.lol and a nomadic clone of matcha_addict@lemy.lol so it's the exact self-same Fediverse identity on Lemmy and Hubzilla.
So it's either this. Immediate drive-by nomadic cloning of your logged-in Fediverse to any instance that you visit for the first time.
Or every Fediverse user must have a user account on every instance of every project out there, and their Fediverse identity must be nomadic everywhere and cloned to everywhere all the same.
Like, you register an account on lemy.lol. Simultaneously, the same account with the self-same credentials will be created on all other Fediverse instances out there. Immediately afterwards, whatever will contain your identity on Lemmy will automatically be cloned to all these other instances of everything. That way, you can immediately use all instances of all projects of the Fediverse just the same.
Or the Fediverse has only one central login server which controls the credentials for all instances of everything out there. You don't register with lemy.lol, you register with this central behemoth. And all tens of thousands of Fediverse instances connect to this central server for login credentials. And, again, your identity with all your data will have to be cloned and mirrored all across the Fediverse.
By the way, I've cloned Hubzilla and (streams) channels before. One channel from one server to one other server. This can take multiple minutes even with not so much content. Guess how long it'll take to clone one identity container from one Lemmy instance to 20,000++ other instances out there.
Yea in theory you wouldn't need the password if you have the private key but here the key is only used for signing, maybe not for login. If it also needs to be backwards compatible. In any case, I don't think user-held private keys is viable.
Sharing with trusted parties... I dunno, I think again it's too technical and complicated to do it. And you'd need people on the platform you trust to already be there.
a bit of text you can send to them by whatever secure side channel you want down to handing them a flash drive
Normal non-technical people are never going to do this. It needs to be easy as clicking a button, otherwise it will never happen for them. Again, this is a neat technical solution but it completely forgets the human.
A Brief History of the Fediverse Symbol
like this
jwphinia and AlexanderESmith like this.
A Brief History of the Fediverse Symbol
A Brief History of the Fediverse Symbol
Recently, a new symbol was proposed to represent the Fediverse. The network notoriously lacks an official symbol, although most people are familiar with the Fedigram, a five-point star made of connectSean Tilley (We Distribute)
like this
Hamiller Friendica likes this.
Just recently read your 2017 article on the different parts of the “Free Network”, where it was new to me just how much the Star Trek federation was used and invoked. So definitely interesting to see that here too!
Aesthetically, the fedigram is clearly the most appealing out of all of these. For me at least.
It seems though that using the pentagram may have been a misstep given how controversial it seems to be (easy to forget if you’re not in those sort of spaces). I liked the less pentagram styled versions at the bottom. I wonder if a different geometry could be used?
The quality about the fediverse that I appreciate the most is the fact that nobody on any of its platforms raised an eyebrow at having a rainbow-coloured pentagram for a logo, until the first Twitter exodus when some newcomer primed for spotting the mildest of outrage-by-proxy gasped, "Have you seen this? Somebody might get upset!"
Meanwhile, the pentagram has been warding off hyperbolic fundamentalists since 2018. The fediverse is much chiller without them. 🤘
My first build - Cantor
Finished my first build, it turned out prettier than I expected honestly. I got a diodeless kit because I had never soldered anything before, it was quite a fun learning experience. Also my first mechanical keyboard, I'm really enjoying the feel of the keys (Kailh sunset).
I was really worried about adapting to the column-stagger, I've only used the regular row-stagger before, but after one hour of practice I was already typing at about half my normal speed, so I'm pretty happy.
I do feel that I need wrist rests though. not sure how to fix that yet.
like this
Banked3-Visa9 and tuckerm like this.
Not medical advice
I would actually advise against wrist rests especially while typing, they are obviously ok for resting but if you don't feel comfortable i think you should at least try a little longer as it probably means that the necessary muscles in your hands are weak and need to develop first. But it may as well be a personal thing so definitely get them if you cant go without.
Looks great btw!
Thanks!
I've been using Logitech ERGO K860 at home before this, so maybe I've just gotten used to the wrist rests. I've noticed that I lift my wrists into the air when I type on the Cantor, so I thought I needed some support. It's actually not uncomfortable and I don't type a lot, so I'll take your advice and try a little longer with this setup. I'd honestly really like to avoid taking up the space on my desk, since I like to write on paper.
Anybody use micro text editor?
i started using micro and its pretty great. but when i try to open the terminal within the editor
ctl+eit seems to just open a whole new terminal window with no context within my document.
anybody got ideas?
What is the command executing when you press this shortcut? Usually you need to use an option with the terminal to execute a command. Most terminals use the option -e COMMAND , but it can be different for a few terminal apps. In example my terminal is "Konsole" and to open a new terminal with "Vim", I need to use this command: konsole -e nvim . Or when I want to use arguments for vim itself, I can do it like this konsole -e "vim -R $HOME/Downloads/test.txt" as an example.
So find out how to do this with your terminal and use that as a command for your ctrl-e shortcut.
micro test.txt sudo can be applied after.
i should be able to open a terminal within the editor and have it appear on the bottom. I should be able to use it to change the settings or style of the micro editor, but it just opens up a whole new instance of my terminal. (which is fish btw)
i'll look and see if i have any arguments to add.or maybe edit the config?
I'm a bit confused. Your terminal is not Fish. Fish is a shell like Bash, which interprets the commands. Terminal is the window application. Based on the linked image, I assume you have Kitty as your terminal? And you want to open a terminal within your editor using shortcut Ctrl-e?
If so, then I don't know about this. I thought you want to run a terminal with micro as the editor from outside of micro, not after you started micro. I might have completely missed your point here then.
It's pretty nice, especially in combination with slurp which lets you select a part of the screen.
I have this mapped to my printscreen shortcut: grim -g "$(slurp)" - | wl-copy, which lets you select a part of the screen to screenshot, and copies the image to the clipboard.
I remember getting excited when it was first announced, then I just never really needed it.
The Insecurity of Debian
There has been a steady uptick of people stating that they will migrate (or already have) to Debian – seeking refuge from what they see as greedy corporate influence. I understand the sentiment fully. However, there’s a problem here that I want to talk about: security.The ugly truth is that security is hard. It’s tedious. Unpleasant. And requires a lot of work to get right.
Debian does not do enough here to protect users.
Long ago, Red Hat embraced the usage of SELinux. And they took it beyond just enabling the feature in their kernel. They put in the arduous work of crafting default SELinux policies for their distribution.
...
However, its default security framework leaves much to be desired. Debian’s decision to enable AppArmor by default starting with version 10 signifies a positive step towards improved security, yet it falls short due to the half-baked implementation across the system.
...
The fundamental difference between AppArmor and SELinux lies in their approach to Mandatory Access Control (MAC). AppArmor operates on a path-based model, while SELinux employs a significantly more complex type enforcement system. This distinction becomes particularly evident in container environments.
...
The practical implications of these differences are significant. In a SELinux environment, a compromised container faces substantial hurdles in accessing or affecting the host system or other containers, thanks to the dual barriers of type enforcement and MCS labels.
TLDR: According to the author, Debian's use of AppArmour is not as effective as RedHat's use of SELinux when it comes to security.
I've yet to see any serious usage of SELinux in the real world
I too have successfully avoided it, but we must acknowledge that not everyone has been so fortunate.
You do know that you can run SELinux on Debian right?
And MAC isn't the end-all for security arguments
It depends on how you set it up and what software you are running.
Use the defaults as a starting point and then move on from there
The threat model seems a bit like fearmongering. Sure, if your container gets breached and attacker can (on some occasions) break out of it, it's a big deal. But how likely that really is? And even if that would happen isn't the data in the containers far more valuable than the base infrastructure under it on almost all cases?
I'm not arguing against SELinux/AppArmor comparison, SElinux can be more secure, assuming it's configured properly, but there's quite a few steps on hardening the system before that. And as others have mentioned, neither of those are really widely adopted and I'd argue that when you design your setup properly from the ground up you really don't need neither, at least unless the breach happens from some obscure 0-day or other bug.
For the majority of data leaks and other breaches that's almost never the reason. If your CRM or ecommerce software has a bug (or misconfiguration or a ton of other options) which allows dumping everyones data out of the database, SElinux wouldn't save you.
Security is hard indeed, but that's a bit odd corner to look at it from, and it doesn't have anything to do with Debian or RHEL.
What does an ordinary RHEL admin do when something does not work?
::: spoiler answersetenforce 0
:::
Everything has security issues. That's a good thing as it means there are people finding things. I do wish Debian was a little faster on patching things but I also understand that they have a limited number of people. There are thousands on packages and a large amount of new security vulnerabilities. Patching takes man power and they only have so much to go around.
Debian isn't this security mess like this person makes it sound. They can be slow on patches but the reality is a lot of these vulnerabilities aren't getting readily exploited in the wild. Just keep up with the security tracker and follow basic security practices such as least privilege and security in depth.
More info: bgammon.org
Source code:
- Server: code.rocket9labs.com/tslocum/b…
- Client: code.rocket9labs.com/tslocum/b…
asante [comrade/them]
in reply to asante [comrade/them] • • •