theoretical considerations on identity management
Fediverse
1
Posts
1
Posters
0
Views
-
so, this is a bit of an abstract mathematical post.
I think that a fediverse service consists mostly of three parts: identity provider, data hoster, and feed provider.
The data hoster is the machine that hosts the posts and comments and upvote/downvote stats. The feed provider is the service which gives you a nice, scrollable overview over new content for you. This is today the same system that provides the data, but it could be separated, such as having a custom "search engine" that gives you content, that you use independently of where the data is stored.
The identity provider basically only makes a proof that "you are you" : you give it your login credentials and it gives you a kind of token that authenticates (proves your identity) to other services. like, i'm on discuss.tchncs.de, but i can post to lemmy.world. this is because the discuss.tchncs.de server says to lemmy.world that i indeed have this account on this server. so they prove my identity in a way.
What i argue now is that such an identity providing server is not technically necessary. You could use something like an
~/.ssh/id_rsafile that you generate on your own computer and use that public key to identify yourself on the fediverse. I don't think that this approach has any inherent advantages over how things are being done today, but it could be done that way and that in itself is fascinating.:D
-
undefined julian@activitypub.space shared this topic
Gli ultimi otto messaggi ricevuti dalla Federazione
-
so, this is a bit of an abstract mathematical post.
I think that a fediverse service consists mostly of three parts: identity provider, data hoster, and feed provider.
The data hoster is the machine that hosts the posts and comments and upvote/downvote stats. The feed provider is the service which gives you a nice, scrollable overview over new content for you. This is today the same system that provides the data, but it could be separated, such as having a custom "search engine" that gives you content, that you use independently of where the data is stored.
The identity provider basically only makes a proof that "you are you" : you give it your login credentials and it gives you a kind of token that authenticates (proves your identity) to other services. like, i'm on discuss.tchncs.de, but i can post to lemmy.world. this is because the discuss.tchncs.de server says to lemmy.world that i indeed have this account on this server. so they prove my identity in a way.
What i argue now is that such an identity providing server is not technically necessary. You could use something like an ~/.ssh/id_rsa file that you generate on your own computer and use that public key to identify yourself on the fediverse. I don't think that this approach has any inherent advantages over how things are being done today, but it could be done that way and that in itself is fascinating.
:D
-
It looks like some issues may arise if/when an instance's domain name changes. Is there any way we can change federation so that we don't need to rely on such a central point of failure?
-
@hendrik@palaver.p3x.de fwiw NodeBB ended up being such a joy to author things in that we switched away from WordPress to NodeBB as our blog. We just blog on our forum.
Now, conflicts of interest are important... I wrote NodeBB, so I am obviously pretty biased :laughing: !
-
Unless you are on a frantic hurry to make this change, I might be able to help. You'll need to migrate to Wagtail, and I have done some work on integration with Wagtail and the Fediverse via the Django ActivityPub Toolkit. But if you do consider this, you'd have to keep in mind that the ActivityPub side of things would be a ongoing experiment.
-
No matter what plugin you find that supposedly will do the job, in my experience it is always a PITA that ends up involving a lot of programming.
I had a good experience with jekyll's wordpress->jekyll import tool. But see below.
I would go for a database-less static site generator like Hugo
Graybeard here, so it's probably just braindamage specific to me, but I've found ruby dependency setup and troubleshooting to be extremely frustrating. Hard for me to wrap my head around.
When jekyll is actually dead (right now it is "only mostly dead") I'll change to something that does not require ruby (eleventy?) or just go back to the nineties and do something barebones with gtml or whatever. Already playing with the latter.
-
Yes. I'm not very educated on the Worpress side of things... Kinda necessary, though, to keep compatibility with the Fediverse AND the No-AI people in my opinion. I mean the Fediverse is kind of the place for people to go if they don't want algorithms and bots to dominate the place?!
-
Our first priority will be to migrate the site as fluently as possible to whatever CMS we transition to. Archiving it as HTML and starting from scratch with a new platform — that's a last ditch effort, I think.
[Edit: I tried to cover the WP fork subject here]
Hugo as a longterm solution isn't going to float with some of our users, I'm afraid. I can vividly imagine somebody turning the old site into a single "Hello world!" page given that kind of permissions.
We will need strictly limited access for contributors, and a clear, friendly input field for text...
-
maybe go for a combination of them
This is a very practical solution... until somebody (I suspect me) has to maintain three or more installs instead of one 🙂 But you're right, this could very well be a way to solve the "one size fits none" conundrum.
As for using a WP fork — the point about the ActivityPub plugin breaking compatibility with ClassicPress makes me wary of this approach. And AFAICT ClassicPress is one of the more reliable WP forks out there? In the long term, I mean.
I'm fine with switching my personal browsers if/when one or the other FF fork turns to the dark side, but I wouldn't want to hop this site between different WP forks the same way...
