Off to the races...
I've officially started on #NomadicIdentity for ActivityPub. I don't expect it to be nearly as challenging as the work on conversation containers because - well we already have a complete and very mature implementation of nomadic identity. This is literally just translating it to a different wire format.
Well, OK, we also have all these Twitter clones to deal with, that will suddenly be forced to implement real online safety, because they'll quickly learn why we've been rolling on the floor laughing at their primitive whack-a-mole blocking technology.
I've officially started on #NomadicIdentity for ActivityPub. I don't expect it to be nearly as challenging as the work on conversation containers because - well we already have a complete and very mature implementation of nomadic identity. This is literally just translating it to a different wire format.
Well, OK, we also have all these Twitter clones to deal with, that will suddenly be forced to implement real online safety, because they'll quickly learn why we've been rolling on the floor laughing at their primitive whack-a-mole blocking technology.
49 Likes
show all 40 comments
Off to the races...
I've officially started on #NomadicIdentity for ActivityPub. I don't expect it to be nearly as challenging as the work on conversation containers because - well we already have a complete and very mature implementation of nomadic identity. This is literally just translating it to a different wire format.
Well, OK, we also have all these Twitter clones to deal with, that will suddenly be forced to implement real online safety, because they'll quickly learn why we've been rolling on the floor laughing at their primitive whack-a-mole blocking technology.
I've officially started on #NomadicIdentity for ActivityPub. I don't expect it to be nearly as challenging as the work on conversation containers because - well we already have a complete and very mature implementation of nomadic identity. This is literally just translating it to a different wire format.
Well, OK, we also have all these Twitter clones to deal with, that will suddenly be forced to implement real online safety, because they'll quickly learn why we've been rolling on the floor laughing at their primitive whack-a-mole blocking technology.
@Mike Macgirvin 🖥️ Great news, Mike! Thank you!
If this gets off the ground, it'll be interesting to see which projects adopt it. It just needs to be peddled hard enough and to the right people.
Digital Identities aren't something unique to the fediverse and it's not something Mastodon could stop if they wanted to. Nomadic identity is coming to the internet. The only question is who is going to own your identity. VISA/Mastercard, your government, Google, Microsoft, or you.
Digital Identities aren't something unique to the fediverse and it's not something Mastodon could stop if they wanted to. Nomadic identity is coming to the internet. The only question is who is going to own your identity. VISA/Mastercard, your government, Google, Microsoft, or you.
The only question is who is going to own your identity.
well... is right now a HZ / Streams Digital Identity just owned by the Account holder? Even so an Admin of a HZ / Streams Hub can´t destroy this kind of Identity completely he still can ruin it very badly... this has to be said.
@Mike Macgirvin 🖥️ Connecting previous digital identities to a current digital identity has come up when working with the education authorities in Norway on the architecture of our edTech ecosystem, and because of Nomadic Identity from Streams and Hubzilla, I actually had something to contribute to the architecture discussion, so thanks! :D
Norwegian government acts as a trusted third-party middleware service on IAM for single-sign on in the education sector, providing a service called Feide, which allows host organizations like local and regional authorities and their schools to choose what data about students, teachers, their groups and duration are shared with Feide, and then service providers with an agreement with the host organisation can get permission via Feide to get access to pseudo-anonymized/anonymized information.
An important part of this is the FeideID given to each person as a unique identifier. However, and this is were my understanding of the situation may be wrong, the FeideID is tied to each local or regional authority, i.e. if the student moves to another municipality, then the student gets a new FeideID, which can be a problem if previous information about the student needs to be transferred from the old municipality to the new one. Hence chaining of identities and nomadic identity came up. :-)
Norwegian government acts as a trusted third-party middleware service on IAM for single-sign on in the education sector, providing a service called Feide, which allows host organizations like local and regional authorities and their schools to choose what data about students, teachers, their groups and duration are shared with Feide, and then service providers with an agreement with the host organisation can get permission via Feide to get access to pseudo-anonymized/anonymized information.
An important part of this is the FeideID given to each person as a unique identifier. However, and this is were my understanding of the situation may be wrong, the FeideID is tied to each local or regional authority, i.e. if the student moves to another municipality, then the student gets a new FeideID, which can be a problem if previous information about the student needs to be transferred from the old municipality to the new one. Hence chaining of identities and nomadic identity came up. :-)
@Haakon Meland Eriksen (Parlementum) Yes, in this case, nomadic identity can help with a seamless transition.
@mikedev This is immensely good news, and I’m overjoyed to hear that you’re working on this. I really want to see Nomadic Identity see wide adoption across the Fediverse.
Is there any chance of Nomadic Identity being specified within a Fediverse Enhancement Proposal, to spell out requirements and encourage projects to use it? I saw there was one for OpenWebAuth, but that’s just one part of Nomadic Identity.
Regardless, thank you for your work. I’m already writing up an article on this. 😁
Is there any chance of Nomadic Identity being specified within a Fediverse Enhancement Proposal, to spell out requirements and encourage projects to use it? I saw there was one for OpenWebAuth, but that’s just one part of Nomadic Identity.
Regardless, thank you for your work. I’m already writing up an article on this. 😁
It's pretty well covered by FEP-ef61 - since we're already supporting ed25519 keys and object signing from my recent work on conversation containers (FEP-521a and FEP-8b32). These all fit together really well. You can thank @silverpill.
Syncing content isn't covered by any existing FEP, but that isn't strictly necessary for somebody to get started with nomadic identity.
Syncing content isn't covered by any existing FEP, but that isn't strictly necessary for somebody to get started with nomadic identity.
@mikedev @deadsuperhero Synchronization definitely needs more thinking, but the general idea has been laid out in "Inboxes and outboxes" section: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#inboxes-and-outboxes
When actor creates an activity, it should be sent to all servers where outboxes of actor's clones are located. This can be done by a primary server, or it can be done directly from a client.
When actor creates an activity, it should be sent to all servers where outboxes of actor's clones are located. This can be done by a primary server, or it can be done directly from a client.
@mikedev here you are yet again doing amazing work. Your contributions are criminally under appreciated. I do hope that this gets adopted far and wide. Thanks for your work!
@silverpill @Sean Tilley Streams synchronises all user activity (profiles, settings, files, everything) - so you've got a perfect near-realtime mirror on multiple servers.
It isn't clear we want to go down that path in ActivityPub. These sync activities are currently very platform specific and there's really no way to generalise them and achieve the same result. I may send custom activities to achieve this at a platform level, but it isn't a priority at the moment.
It isn't clear we want to go down that path in ActivityPub. These sync activities are currently very platform specific and there's really no way to generalise them and achieve the same result. I may send custom activities to achieve this at a platform level, but it isn't a priority at the moment.
@denkyemx @mikedev Solid is a fascinating project, and there's a lot of interesting work in making Solid and ActivityPub work together. ActivityPods is definitely worth looking at.
However, the architecture is so alien to how most Fediverse platforms work, that it would be truly painful to retrofit onto existing platforms. It's like using Google Drive and files to build a database, on a per-user basis. Most Fediverse platforms use actual relational databases.
However, the architecture is so alien to how most Fediverse platforms work, that it would be truly painful to retrofit onto existing platforms. It's like using Google Drive and files to build a database, on a per-user basis. Most Fediverse platforms use actual relational databases.
@deadsuperhero @mikedev @denkyemx yes I try to understand https://semapps.org/ but I'm at the foot of the mountain :baduk:
While TBL's new open letter addresses common problems, why he insists on the Solid protocol when we have something that works is strange. https://medium.com/@timberners_lee/marking-the-webs-35th-birthday-an-open-letter-ebb410cc7d42
@Haakon Meland Eriksen (Parlementum) Even stranger when you consider that TBL should know that there are Zot, Hubzilla, Nomad and (streams). He was told, and he seemed to acknowledge it.
It's either because he has quickly forgotten about it again, or because he can't imagine that it's in daily use rather than experimental, although even experimental would be much more advanced than Solid, or because he doesn't want to stop his brain-child Solid again, and he wants to push it through and establish it as a standard before the general public learns about Zot and Nomad, Hubzilla and (streams).
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #TimBernersLee #Solid
It's either because he has quickly forgotten about it again, or because he can't imagine that it's in daily use rather than experimental, although even experimental would be much more advanced than Solid, or because he doesn't want to stop his brain-child Solid again, and he wants to push it through and establish it as a standard before the general public learns about Zot and Nomad, Hubzilla and (streams).
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #TimBernersLee #Solid
@Haakon Meland Eriksen (Parlementum) Not any stranger than publishing his open letter on a proprietary platform instead of his own web page. (I at least assume he has a web page of his own...)
But I've had the feeling from the beginning that Solid was never really about solving a problem, but about inventing a solution. It's not that it's a bad idea, but hardly unique. The FreedomBox already had many of the same goals and ideas, and famously sparked the development of the Diaspora software.
Instead of joining the existing community, I have the feeling that Solid is about replacing it, and in the end (although they don't say so yet) — commercializing it.
But I've had the feeling from the beginning that Solid was never really about solving a problem, but about inventing a solution. It's not that it's a bad idea, but hardly unique. The FreedomBox already had many of the same goals and ideas, and famously sparked the development of the Diaspora software.
Instead of joining the existing community, I have the feeling that Solid is about replacing it, and in the end (although they don't say so yet) — commercializing it.
Solid is kind of a mirror image of nomadic identity. The way I understood it is that all your data for everything you do online is stored under a single location that you control, and you provide to multiple other people/services from there. Those services could be identical services in different locations operating on the same data. So the services themselves could be nomadic and running on different servers. In that respect you're safe from any of these servers going down. But there's a single point of failure. Your data. Lose it and you've got nothing.
Since Solid appears to focus on data storage rather than the social aspect, in theory, it could be integrated into Hubzilla's Cloud Storage / File Manager functionality. That way there would be three ways to access the same data: Web, WebDav, and Solid.
I am not sure if Solid has the concept of clones or syncing, but if not, Hubzilla could sync files between clones, perhaps using Zot or another method. That would help mitigate the single point of failure problem.
I am not sure if Solid has the concept of clones or syncing, but if not, Hubzilla could sync files between clones, perhaps using Zot or another method. That would help mitigate the single point of failure problem.
@Mike Macgirvin Is this going to be full "Nomadic Identity" (with clones and syncing) or will it be "Portable Identity" (you can move your identity to another host/platform)?
So far it sounds like you are implementing Portable Identity, with the hope that they implement the full Nomadic Identity stack at a later time.
So far it sounds like you are implementing Portable Identity, with the hope that they implement the full Nomadic Identity stack at a later time.
@Scott M. Stolz
As far as I can see, it doesn't. It works wholly differently from nomadic identity.
Currently, Hubzilla hubs are like clients with full data storage that sync their data peer-to-peer.
Now imagine Hubzilla hubs being thin clients with no data storage whatsoever. Next to these hubs, there's another kind of server where your data is stored. Let's call it data server. It's fully independent from the hubs where you have your channel.
You can have as many instances of your identity on as many thin client hubs as you like. One goes down, doesn't matter, you've got more. But all your data is stored on one data server. With one account. One. Every last one of your channel clones on all those thin client hubs is connected to this one data storage.
You may be able to choose where to park your data. But you can only choose exactly one data server where you want to park your data for all your channel clones. You can not clone or mirror your data storage. You've only ever got one instance of that.
If that server goes bellies-up, have fun starting over from scratch. If you're lucky, you may have a backup. If you don't have an up-to-date backup because you haven't made one in a while, or you've never made one in the first place, well, then you're fucked.
It'll be even more fun if Solid won't let you make backups of your data in the first place.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Solid
I am not sure if Solid has the concept of clones or syncing,
As far as I can see, it doesn't. It works wholly differently from nomadic identity.
Currently, Hubzilla hubs are like clients with full data storage that sync their data peer-to-peer.
Now imagine Hubzilla hubs being thin clients with no data storage whatsoever. Next to these hubs, there's another kind of server where your data is stored. Let's call it data server. It's fully independent from the hubs where you have your channel.
You can have as many instances of your identity on as many thin client hubs as you like. One goes down, doesn't matter, you've got more. But all your data is stored on one data server. With one account. One. Every last one of your channel clones on all those thin client hubs is connected to this one data storage.
You may be able to choose where to park your data. But you can only choose exactly one data server where you want to park your data for all your channel clones. You can not clone or mirror your data storage. You've only ever got one instance of that.
If that server goes bellies-up, have fun starting over from scratch. If you're lucky, you may have a backup. If you don't have an up-to-date backup because you haven't made one in a while, or you've never made one in the first place, well, then you're fucked.
It'll be even more fun if Solid won't let you make backups of your data in the first place.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Solid
@Scott M. Stolz I'm not even sure if full-blown, Hubzilla-level nomadic identity is even doable without moving away from the Fediverse standard "account = identity" and towards Hubzilla's multiple-channels-per-account model.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #NomadicIdentity
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #NomadicIdentity
@Jupiter Rowland
If I were to add it to Hubzilla, I would not implement it like that. As you said, with Solid by itself, you only have one copy of your data. That is dangerous.
Instead, the existing Hubzilla Cloud Storage would become a Solid Pod (by implementing the Solid protocol as an additional interface). So all of the existing features supported by Hubzilla and Zot are still intact.
It would work similar to how ActivityPub interacts with Zot. Zot understand that the two clones are the same identity, but ActivityPub considers them two different identities. In this case, Solid would consider the two Zot clones to be two independent Solid Pods.
Not ideal, but at least you have two copies of your data, instead of one, even if Solid thinks they are two different Pods.
Now imagine Hubzilla hubs being thin clients with no data storage whatsoever. Next to these hubs, there's another kind of server where your data is stored. Let's call it data server. It's fully independent from the hubs where you have your channel.
If I were to add it to Hubzilla, I would not implement it like that. As you said, with Solid by itself, you only have one copy of your data. That is dangerous.
Instead, the existing Hubzilla Cloud Storage would become a Solid Pod (by implementing the Solid protocol as an additional interface). So all of the existing features supported by Hubzilla and Zot are still intact.
It would work similar to how ActivityPub interacts with Zot. Zot understand that the two clones are the same identity, but ActivityPub considers them two different identities. In this case, Solid would consider the two Zot clones to be two independent Solid Pods.
Not ideal, but at least you have two copies of your data, instead of one, even if Solid thinks they are two different Pods.
@Scott M. Stolz
I don't see it as dangerous at all, i see it as a feature. As a self-hosting person i do want exactly that one copy on my own server.
I do not want my data in an external cloud, nor on an external server, which i do not control.
For a copy (or a 2nd copy), e.g. backup i do have redundant daily backups already as part of my hosting account.
If I were to add it to Hubzilla, I would not implement it like that. As you said, with Solid by itself, you only have one copy of your data. That is dangerous.
Instead, the existing Hubzilla Cloud Storage would become a Solid Pod (by implementing the Solid protocol as an additional interface). So all of the existing features supported by Hubzilla and Zot are still intact.
I don't see it as dangerous at all, i see it as a feature. As a self-hosting person i do want exactly that one copy on my own server.
I do not want my data in an external cloud, nor on an external server, which i do not control.
For a copy (or a 2nd copy), e.g. backup i do have redundant daily backups already as part of my hosting account.
your approach is more security-oriented: don't trust anyone, keep all copies yourself. the other one is more practical: if one server is out for some reason, temporarily or permanent, continue seamlessly on the next one. either one works for me.
@phanisvara (streams) Convenience is the no# 1 reason to knock out privacy, security or safety concerns. No pun intended, but one's fate with such issues is self-chosen.
@_jayrope
I never said you have to backup your data with some giant corporation or on a third-party server.
The dangerous part I was talking about is not having backups of your data.
If you have your data on one server, with no backups whatsoever, you are screwed when something happens to that one server. Because you have no way to restore the data once it is gone since that was the only copy.
It does not matter if you backup you data on a different hard drive, or on another self-hosted clone of your account.
Having a backup has nothing to do with where you store the data. You can store the data anywhere you want. If you want your data to be safe, have a backup somewhere.
I don't see it as dangerous at all, i see it as a feature. As a self-hosting person i do want exactly that one copy on my own server.
I never said you have to backup your data with some giant corporation or on a third-party server.
The dangerous part I was talking about is not having backups of your data.
If you have your data on one server, with no backups whatsoever, you are screwed when something happens to that one server. Because you have no way to restore the data once it is gone since that was the only copy.
It does not matter if you backup you data on a different hard drive, or on another self-hosted clone of your account.
Having a backup has nothing to do with where you store the data. You can store the data anywhere you want. If you want your data to be safe, have a backup somewhere.
of course, i'm aware of that. but if i lose my social networking data, or somebody else gets hold of it, nothing really bad happens. i value the principle of privacy, but getting down to my own privacy, i don't care very much. i don't even use an adblocker, happy that website operators can make a few cents from my visits. i don't have any disposable income or money, means i'm immune to advertisement. and if people or organizations know where i go online, they're welcome to get bored. if i want to read something w/o disturbance i use my browser's reader mode and have peace.
@_jayrope
That is why you have it set up like this:
Primary Server: self-hosted Clone Server: self-hosted
Since they sync, you have a hot backup that can be used immediately without the need to restore any backup files. This is safer and more convenient that trying to restore files from a backup that might not even work.
Just because it is a clone does not mean it has to be on someone else's server.
I do not want my data in an external cloud, nor on an external server, which i do not control.
That is why you have it set up like this:
Since they sync, you have a hot backup that can be used immediately without the need to restore any backup files. This is safer and more convenient that trying to restore files from a backup that might not even work.
Just because it is a clone does not mean it has to be on someone else's server.
@Scott M. Stolz Although this would ideally require two residencies that are far away from each other that it's hard to deal damage to both at the same time, but close enough that it isn't too inconvenient to travel from one to the other. Both would have to have electricity and landline network permanently on so that one server can run in each.
@Scott M. Stolz That's true. It would require double administration, though. More importantly, to me, is that i actually do enjoy a complete loss of data every once in a while :) It's the best filter for dead connections i know :) But, no, it's appreciated, thank you. Didn't think of cloning onto "myself". Interesting idea, metaphysically.
@_jayrope As @Jupiter Rowland mentioned, the downside is that it requires double administration, but on the upside, if one goes down, the other is already live and ready to go.
It also depends on the nature of the data you are self-hosting.
I have stuff that took me days, months, or even years to create. Losing something like that would set me back significantly. I would have to start over from scratch. And I have data (scripts, courses, ebooks, software licenses, etc.) that I actually paid for. Losing those would mean I have to pay for them again, in some cases.
And since I use some of that in my business or open source projects, taking time to restore backups could interrupt my flow. So having a live hot backup that I can switch to immediately is a plus.
But, different people have different data and needs. So what I need isn't necessarily what other people need.
It also depends on the nature of the data you are self-hosting.
I have stuff that took me days, months, or even years to create. Losing something like that would set me back significantly. I would have to start over from scratch. And I have data (scripts, courses, ebooks, software licenses, etc.) that I actually paid for. Losing those would mean I have to pay for them again, in some cases.
And since I use some of that in my business or open source projects, taking time to restore backups could interrupt my flow. So having a live hot backup that I can switch to immediately is a plus.
But, different people have different data and needs. So what I need isn't necessarily what other people need.
@_jayrope
In reference to what? Backups of data?
That might work for publicly posted data, but that would not work for anything with access control or private discussion groups. So things stored in your Hubzilla Cloud or in a Solid Pod that require authentication would not show up (and should not show up) in Archive.org.
https://archive.org?
In reference to what? Backups of data?
That might work for publicly posted data, but that would not work for anything with access control or private discussion groups. So things stored in your Hubzilla Cloud or in a Solid Pod that require authentication would not show up (and should not show up) in Archive.org.
@Scott M. Stolz Not only double administration, but two separate physical locations for the servers.
If you've got two hubs, and you host both on your own iron, but one is running in your house, and one is running in your garage, then one and the same natural disaster is likely to wipe out both at the same time. That's why you need to have the clone running on a server in a building in another town far enough away. And you need to pay for the place where the clone server is running.
If you've got two hubs, and you host both on your own iron, but one is running in your house, and one is running in your garage, then one and the same natural disaster is likely to wipe out both at the same time. That's why you need to have the clone running on a server in a building in another town far enough away. And you need to pay for the place where the clone server is running.
@Jupiter Rowland
At the very least, they should be on two different machines. A computer crashing or data being corrupted is more likely than a natural disaster. And if one of your hot backups is on a laptop, you can take the laptop with you.
Part of it depends on how vital the information is. Ideally, data that is vital has an off-site backup or is on an off-site server. Both can be self-hosted, if you want. But, realistically, most people are not going to do that unless the data is mission critical and they have a budget for it.
Not only double administration, but two separate physical locations for the servers.
At the very least, they should be on two different machines. A computer crashing or data being corrupted is more likely than a natural disaster. And if one of your hot backups is on a laptop, you can take the laptop with you.
Part of it depends on how vital the information is. Ideally, data that is vital has an off-site backup or is on an off-site server. Both can be self-hosted, if you want. But, realistically, most people are not going to do that unless the data is mission critical and they have a budget for it.
Conversation Features
Loading...
Login
Login
- Copyright © 2024 WisTex TechSero Ltd. Co. All rights reserved.
Web hosting provided by TechSero Web Services.