-

Thu, 11 Mar 2021 01:00:13 +0100

adminsforum@hubzilla.org

Stuart Croall schrieb den folgenden Beitrag Thu, 11 Mar 2021 01:00:13 +0100

Problem ressurecting a hub and channel

I had a hub at hub.otherwise.social hosted on yunohost, with a channel named "stuart." I didn't use any of it much, and life events left me distracted and neglectful of my server. This year, when decided to revive it, I elected to start over with a fresh install, given how little I had used it. I did not restore from a backup.

Now I have essentially replicated the same setup, at the same domain. My first channel I again named "stuart." Everything seemed to be working fine until I tried to connect to the Hubzilla Support Forum and, after a while, noticed I wasn't seeing anything in my feed. I had reconnected to some people from Mastodon, and was seeing their feeds without a problem. When I tried to connect to my channel from my Mastodon account, the information that showed up (including my banner image) was from my previous "stuart@hub.otherwise.ca" channel, despite the fact that I had overwritten the previous Yunohost/Hubzilla install.

Based on this I assume something about my previous channel persists somewhere, despite I am wondering if I have "burnt" that channel name at that domain on Zot6? Or whether it is a function of the old identity persisting in the connections of others and, if those connections were deleted from the other end it would function again?

My assumption has been that it has something to do with how Zot6 identities exist independently of channel and domain. And, so, there is a conflict with my first "stuart@otherwise.social" channel and my second one which, despite having the same name, is identified by a different Zot ID? That's how I'm thinking of it at a high level, anyway.

It's not really the end of the world either way; I'll just rock my new channel. I'm mostly trying to understand how this works so, in the future, I can pass on good advice to others (and my future self) ;) I'm hoping to build for the future now, so I'll definitely be more attentive to keeping backups :)

Thanks for your help!

show all 43 comments

Thu, 11 Mar 2021 01:42:28 +0100

FourOh-LLC

fouroh-llc@hubzilla.factoryfouroh.net

I have no idea what to do but going to follow and see how this ends, good luck!

Thu, 11 Mar 2021 05:10:21 +0100 zuletzt bearbeitet: Thu, 11 Mar 2021 05:10:37 +0100

hEARt PhoniX

tobias@hubzilla.rocks

The channel name is mererely a human readable representation, as far as I understand. The mashine readable representation is a long hash. A human readable channel name cannot appear twice on a hub, but that's another story. Also a hub is identified by such a hash afaik.
I have no idea how other systems handle that.
What worries me is that the information a remote diagnostics /zot_probe returns for souperate@hub.otherwise.social is ... nothing.
Which is obviously suspicious.

Maybe someone else can pick up from here.

Thu, 11 Mar 2021 06:00:53 +0100

Tanja

tanja@hz.lazyteddy.eu

@hEARt PhoniX

hat worries me is that the information a remote diagnostics https://h.lazyteddy.eu/zot_probe returns for souperate@hub.otherwise.social is ... nothing.

What did you put in? The channel name or URL? When I put the channel URL in, I do get a result. Not that have any idea what it means; I didn't even know this page existed until I saw your post.

@Stuart Croall
@hEARt PhoniX's answer is otherwise correct; there's a cryptographic key (I think) for each channel which is generated at channel creation. The hubs where you had connections with your old channel will still have the old key stored, so you can't reconnect to them with a new channel with the same name and domain. If you want the same name, you need to create a new subdomain. This is a security matter, and it's the same reason you can't reuse a channel name on the same hub after you delete a channel. Otherwise, somebody else could pick up the name, and connections of the deleted channel wouldn't know. While the chances in the real world right now are slim, it's also possible that somebody could pick and abandoned domain name and create a new hub with the same channel name, which is obviously not desirable.

Thu, 11 Mar 2021 10:22:05 +0100 zuletzt bearbeitet: Thu, 11 Mar 2021 10:23:35 +0100

hEARt PhoniX

tobias@hubzilla.rocks

@Tanja Bam! Facepalm.
Intresting bit: I do get a return for exmample tanja@h.lazyteddy.eu, some info for your hub.
But this is what I wanted. This is what was intended.
The channel id by which your channel is identified in Zot:

    "id": "BSDM7fdFLmpcTKDxlW3KDruGSg8PV7dGwvu8yqKwDmPxo6xw1JhGRsZ4bSW6Jkc1vgajvVE9CpTGScFqBcz9GA",

    "id_sig": "sha256.YW4tFZKQ3JmNOaHwST-uCdDDpj_bLlWHpNbU59J5kzNCemjXfcTz0GSVoMwMylo65fDsYUcncVmlQVRUCqopCc5NnMpR6nKgsFU07OmIQSatlNODS-3ir0Dbl5JrknfKqdFesR66epnU5ZgwaNc2DdyaPJzF0PLBkQL05kTBjfQ2MOeHDQVpQGDfB5R4JQP8a6-xsNCKwlrRGMDhAJDWf81kW0HJ-iz5YWH0yySrTnG61WBJiOCMLqKzsQZ7wPZ9caYARQfQ_eHg9ZXoAtrdRwzQu69OEj0PacgkcJsSlEBtZ1NRynDW-jTB-k3QAA5TOn2oc2UW0kTgSnteDGKQayJ6RlLle2FRPVW9nV_D3H-QkUi3vqX-kyxksKhUgQVTDIY8H9CRhxlPs39qqxe_NYKpmmlswGD6PJl3wqtR2xxEK-eYdYM6eyW7tovACDv0TwnagxfbSFghUKcdw_UA0S4HdP9EtIf7MrRsw2y0yEFpFHP2T25SeGY-2yJ0m8SMR3jJi8w33ldZA8JRUhxb6TFPR7gHDMWDBhYoLNnGt6ZwXuFn1hyTKiirz3tpxKVusWQkN9aes7u8vdVlfUMxK7_6N_R6uLpSPFFrYQVgly-QeF6lxXv9CCsrIkwzv5Qz25CyW0DHfk5OEIjPOPwDMv-hdHZJDLSZ09lWavzFpN4",

This is what the software uses. I'd like to challenge @Tanja that if you use the same URL but install a new hub you will still be able to use the same channel name in Zot. Because it's a different hub, with a different ID. The DNS name is just used for name resolution.
What I don't know is how it's exactly solved:
Hub aaabbbccc is deleted
hub bbbcccaaa is new
hub cccaaabbb is seeing no answer from aaabbbccc, therefore it is marked as inactive, and if it does not return, dead. Similar mechanics work for hubs.
hub aaabbbccc is new and unique, therefore able to communicte.
You are a newborn channel, need to start from fresh.
For Zot.
Now ... this may be because Zot is nomadic. I guess you will be right for other protocols such as AP etc, which is why they are not nomadic.
Wich means, you may be right, @Tanja.

@Stuart Croall or @Stuart Croall

    "primary_location": {
        "address": "souperate@hub.otherwise.social",
        "url": "https://hub.otherwise.social/channel/souperate",
        "connections_url": "https://hub.otherwise.social/poco/souperate",
        "follow_url": "https://hub.otherwise.social/follow?f=&url=%s"
    },
    "public_key": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtLNimjGxsFAyC8VlnIdy\ngdLXXkkGDqQR8YwtS+MggNP3mZJttyQEbp5Pd6AzGNctjK8R1OkOIj2LrNJSin/S\nmW+RZFI1BQG3ZzCp851bqiAJ5h+JgTYEsIxS2B8PNkb5j+nSEPgcdvEjuOVGTkLf\ngSBYwbWzNT2NGWBDCz41LzmSxqbeXnhSiCWFmMrOJ71WPi63q4LzA/rcrxnrQr9Z\nTsj3EpQn7DxPoXYYY3HQitzCLQ+BttK5zu5rRrHapTSveNsKSHppxU8JKRkAt11X\nuf/nAPk1w1Ux/x2oZZm4L5MpreZ8HwZvvRf9fvK2vN7BAOZX3c8rS2FoU7XDCsrk\nHh0RnPuyhujQbUOX1EhyAYxxpIAHf4m5eT2ZcyaaNenQ4iJmzjwpiJkgnlwqXVKB\nk4nXmDYvN2SPa+uDrfP1X5DVkqleZptzL+D/zgY/DS1S7zeh6MtiFItt2vn5IaEh\nnJLNVgvb/RWohk6GcepVJfOsytTpLdjzB1AMm1qmyccX3WI+7LrPN2iSqkh/r7kJ\nFwkG4+htvASsBTsEl9iwYCM2DROrcdwt/cSuSnNnw0OR2UUTsl83vJ0Vqsjit77v\nLjZX1wDjgDRGBHa/DQXybRAJKcFIQXO7aIkssRQTCx5bAQrQ8cykiieAfRwCrFLg\n6AZD4EHR2FJ9bL7YfTq+aR0CAwEAAQ==\n-----END PUBLIC KEY-----\n",
    "username": "souperate",
    "name": "Stuart Croall",
    "name_updated": "2021-03-04 19:27:55",
    "photo": {
        "url": "https://hub.otherwise.social/photo/profile/l/3",
        "type": "image/jpeg",
        "updated": "2021-03-04 19:44:57"
    },
    "channel_role": "social",
    "protocols": [
        "zot6",
        "zot"
    ],

The old channel sig is:

[id] => 'WMY4JIdoR2WTsU5ycJWyfgT419ofALra8C4bGBDcC81IGwqE1oe2NhLdFiR_eRXFMmTLoh6FJwl0JH-8S6Aoig',
        [id_sig] => 'sha256.RAVnyMRpOmoBVpyb4S6fPtbhld6BudJGnpZit1UzWwpL4xiN0GGtSz5dip2EIM9cwr0I2PPRWPHo8MP5HGeEo90AQzVY48Rp8q6inO2Oaqr6zYISo6aKe9kwfBGxOGJ7FEDqLeDeDjbJ_rWYXId5pesD0qh86SrTz9BErd7pqGnVUNAR_5pAjLCM4HZ4BRiGdWF1sIAJ_a88gC3bmFnNw8PAwvRCpmv5xC56iJ3Vpt_2gNcBTIAHRRjf0eKazWKNd6Urc-WsHuY9b9OeAZDH_lhuN3FJ_zjhSJ4qHciMj-o0ucQNUOwMLRhmI58GsLVQJc61s7LRdyNzKl-NuerMbQ67tIugk6Sti7Jf2GC4JV7T8dIXWlQ5cVPXlsRR0pbgtZMjaUfJG7Cy9I214mOeOIyyk8AQcNqFN4XwhbX-Og5joMs5dQ9pQFESKULcPnqn9DSApUxEoEV1PgHTDDbWK70sNEUA4_Oh50mkB0lgO0VGQBZIeNTVPGEqaU7KQSnFagmn1Y6Vgt8mxOcg7asTwvJHwyJqFXnT2mlbWRiE22jH92vISInT7DPwZIvR0lnWlEdlY95Cyu6tFOBpOyvdVfo3QXvCRcI3G3_gl3wc9h-3CMzwqJs14Sf8mqtScv4RfG3ljNUAqfGnn9She5yEFaDYuPUSE3dKP9ddBFBi5cw',

You can compare the old channel https://hub.otherwise.social/channel/stuart
and the new channel, as long as the old one is not yet marked dead. This is what I wanted to do.
As an educational experience at the expense of @Stuart Croall - but I hope we all will learn a bit. Or get confused. Or both.

Again, as you, @Stuart Croall mentioned Mastodon, I think @Tanja is right, that the may be confused now. I don't know, though.
And there should be no reason for problems with Zot based channels.
This is another interesting issue. I have been seeing similar behaviour with other channels too, recently. Even direct messages written to me never seem to have reached my channel.

Thu, 11 Mar 2021 11:06:30 +0100

This is worrying. Are there other federated apps that would handle it like that too?

Thu, 11 Mar 2021 11:56:34 +0100

hEARt PhoniX

tobias@hubzilla.rocks

@HansWolters
What do you mean, what exactly is worrying?

As of now for any non-Zot protocol there is no nomadic identity, no cloning. Which means if you clone your channel you will need to send a new connection request to non-Zot services.
I remember Mike once wrote he had solved this (for Zap), but cannot locate that post. If so I guess after more hard work by Mario it will land in Hubzilla. But that behaviour (nomadic ID) goes against the current nature of anything else but Zot. And every inter-protocol communication comes at a cost.
I remember seeing some initiative into this direction for AP, but cannot find to check if it has grown.

This is an old discussion on the same subject, but seen from the other angle. From 2018, referenced here for some background info how much effort all this requires from many sides.
https://github.com/pixelfed/pixelfed/issues/216

If the DNS goes down or changes, then every single AP implementation needs to do its own deduplication, in its own database. On the other hand, zot doesn't need to dedupe anything because the GUID is globally unique.

Note that this doesn't prevent exporting a profile's posts and importing them somewhere else; however, it does mean that this will break profiles for any software that is unaware of the concept of accounts moving, e.g. Mastodon. At the moment, Mastodon converts all ActivityPub Objects into its own database format. Webfinger is used not only for lookup, but also to create a username/domain pair that identifies every single user the server is aware of. So what might federate out as mastodon.art/users/55816 is irrelevant, because Mastodon then stores that response as @krita@mastodon.art and refers to it internally as such. When mastodon.art's admin changed the username from krita to Krita, a lot of Mastodon servers stored "user 55816" as a separate profile, leading to duplicate krita/Krita profiles on those servers.

The main takeaway here is that the ActivityPub spec doesn't cover what to do with an object after lookup; that's left entirely to the software. The only constraint is that ActivityPub ID should be dereferencable and globally unique; as a consequence, most implementations (i.e. Mastodon/Pleroma) simply tie this to the DNS, because each domain has its own unique namespace. Moving from one server to another would therefore mean re-federating out your profile as a different URI, with the burden of deduplication falling on the server software that you federate with. If the remote server doesn't dedupe the Object it receives after URI lookup, it will simply store it as a separate Object.

Thu, 11 Mar 2021 17:35:06 +0100

Stuart Croall

stuart@hz.otherwise.social

Wow! Thanks @hEARt PhoniX and @Tanja for really diving into this. I had no idea it would elicit so much discussion; I guess I imagined it would be more of a "yup, sorry, that's how it works" kinda of response. I should know better by now that the Hubzilla community invests a lot of time and energy supporting each other :)

As an aside, I apologize for littering the Fediverse and Zotiverse (is that a thing?) with Stuart Croall identities while I've been learning and experimenting. I'll try to settle down ;)

For what it's worth, when @hEARt PhoniX tagged my two channels ("stuart" and "souperate") I got a notification at "souperate" but not at "stuart"..

I'll have to read through some of the comments again to wrap my head ahead everything that was shared. Going forward, I'll use my "souperate" channel as my main channel. I'll keep "stuart" around out of curiosity; I'm interested to see if anything about its status with Zot channels changes over time.

And I'll remember that deleting a hub, and then reinstalling it fresh, with the same channel names, is not as simple as it sounds ;)

Thu, 11 Mar 2021 18:30:14 +0100

FourOh-LLC

fouroh-llc@hubzilla.factoryfouroh.net

That's just it, if you want to build a community of any size on top of Hubzilla these things going to become vitally important. I am not a developer or even a coder, and I do not do much around here as I have no idea what's happening is a 'bug or feature'. For example I never used Profiles because multiple hubs (I run four) and channels are already giving me a serious workload. I guess after I mastered everything else I might mess with Profiles, but not before.

Subterrel Thu, 11 Mar 2021 18:47:23 +0100

Stefan Haydn

sh@hub.hayfidelity.de

@Stuart Croall Hi there, I had a similar problem. I have reactivated my hub after a while and also choose the same channel name. I ended up using a new channel name, as there sure is a lot of confusion with those "new installed old channels". I had a lot of errors in delivery report (you can find that when clicking on the wheel down right on a post of yourself), because some of my old contacts had me still as follower on their side and that generated a lot of errors. They even couldn't see my posts. New connection were good. So now I have my old channel renamed to forward to my now actual channel. @please connect to sh@hub.hayfidelity.de is the old one, this is my new.

Thu, 11 Mar 2021 19:00:24 +0100

Max Kostikov

kostikov@zotum.net

@Stefan Haydn

I have reactivated my hub after a while and also choose the same channel name.

For security reasons it's not possible to reuse channel name after deletion or hub reinstall from the scratch.

Saleucami Thu, 11 Mar 2021 19:23:35 +0100

Stefan Haydn

sh@hub.hayfidelity.de

@Max Kostikov Yes, it is. How should a newly installed hub know what channels were on an older install on a different server?

If the old server hadn’t been completely wiped and the channel would have been just deleted, you are absolutely right. Then the database would know there has once been that channel and it couldn’t get reactivated.

Thu, 11 Mar 2021 19:44:19 +0100

Max Kostikov

kostikov@zotum.net

@Stefan Haydn

How should a newly installed hub know what channels were on an older install on a different server?

The problem is not how to find out whether there was previously a channel with such address or not.
If you previously created and used a channel then its public key was distributed over the network and saved on other hubs. When you re-create a channel you'll generate new keys but you will not be able to use them to communicate with hubs that already store their previous version.
This avoids the chance of using your identity or spoofing data sent on your behalf.

Thu, 11 Mar 2021 19:49:21 +0100

hEARt PhoniX

tobias@hubzilla.rocks

@Stuart Croall

As an aside, I apologize for littering the Fediverse and Zotiverse (is that a thing?) with Stuart Croall identities while I've been learning and experimenting. I'll try to settle down ;)

Do not worry, time will deal with that. As I mentioned there is a mechanism to deal with dead hubs, anything else would be stupid, just like channels. If a channel is no longer reachable by a directory server, the delivery attempts will become longer until finally the channel is being marked "dead". If you are connected to such a channel you will see that after I think a month it is marked as "archived". If you write posts that would usually be sent to those channels your hub will no and initiate no delivery attemts at all.
I am not sure how it works when a channel comes back, I guess it should be reactivated, but I am not sure as I have not yet tried this.
Remeber, you can download your basic channel data (up to more extended backups of your posts), delete your online channel, leave the hubiverse for good and if you happen to decide after some time to make a return, search for a hub, upload your json file and continue where you left off, your new (old) channel will pick up with the old settings, connections at al.
Same with clones. You can change hubs by cloning and chaning your primary channel and if I am connected to you I will not even notice that you are hopping around the globe, unless I visit your channel and happen to know the old URL.
The usual disclaimer applies: Zot.

Thu, 11 Mar 2021 20:09:04 +0100

Stuart Croall

stuart@hz.otherwise.social

Thanks @hEARt PhoniX

I will keep all those options in mind (exporting, cloning etc). I was aware of a lot of those options, in theory, now I just need to practice them ;)

Thu, 11 Mar 2021 20:40:59 +0100

Witcraft (inactive)

witcraft@hub.witcraft.de

OK, this might explain my problems, too. About a year ago, I had a vServer with the same subdomain and same channel ID. As far as I remember, I had no connections back then (at least not outside Zot), as I was just dipping my toe into h-zy water, but it might be related...

So @hEARt PhoniX , I understand that my subdomain / channel combination might be "burned" (leading to the problems with direct messages you mentioned). Is there a way to find out - before I, on suspicion, export and burn down all I created so far, re-create and import it? I understand that previous connection data needs to be secured from abuse (so noone can pretend and hijack) - but can't, in Zot-land, old administrative shell data just be eradicated and set up new, to start out with a fresh green lawn with the core element (nomadic identity)?

If it is a recent system bug, I would hate to lose my identity because of a history of testing...

Thu, 11 Mar 2021 20:51:56 +0100 zuletzt bearbeitet: Thu, 11 Mar 2021 21:08:29 +0100

Max Kostikov

kostikov@zotum.net

@Witcraft

but can't, in Zot-land, old administrative shell data just be eradicated

As @hEARt PhoniX said you can use channel export / import to save all you data. Dump also includes channel keys.
But I don't sure if this will work with new hub on the same domain (I quess it won't).
I believe Mike or Mario can tell you for sure.

Thu, 11 Mar 2021 20:54:41 +0100

Tanja

tanja@hz.lazyteddy.eu

@hEARt PhoniX

And there should be no reason for problems with Zot based channels.

Except I did have issues doing the same thing, although with Zap. When I first tried Zap, I didn't keep the instance. Then I wanted to set up a new one a few months later, used the same subdomain and channel name I had before, and I ran into very similar problems.

Thu, 11 Mar 2021 20:59:18 +0100 zuletzt bearbeitet: Thu, 11 Mar 2021 21:02:08 +0100

Witcraft (inactive)

witcraft@hub.witcraft.de

@hEARt PhoniX

Same with clones. You can change hubs by cloning and chaning your primary channel and if I am connected to you I will not even notice that you are hopping around the globe, unless I visit your channel and happen to know the old URL.

It would be important to know, though, if you can visit every place in the world only once with the same passport... ;-) (or get someone to rename the hotel for you...)

Thu, 11 Mar 2021 21:00:04 +0100

Tanja

tanja@hz.lazyteddy.eu

@Stefan Haydn

Yes, it is. How should a newly installed hub know what channels were on an older install on a different server?

The statement by @Max Kostikov seems to require a little elaboration. You are correct in that it's possible to set up a new instance with the same domain / channel name combination, but it will create communication problems, as you said you already found out for yourself.

Thu, 11 Mar 2021 21:01:55 +0100

Tanja

tanja@hz.lazyteddy.eu

@Stuart Croall

I guess I imagined it would be more of a "yup, sorry, that's how it works" kinda of response.

Not a big fan of those myself, so I always try to explain at least as far as I understand things.

Thu, 11 Mar 2021 21:19:19 +0100

Tanja

tanja@hz.lazyteddy.eu

@Max Kostikov I think there's a slight lag here; when I wrote my answer, yours hadn't gotten through yet :-)

Thu, 11 Mar 2021 21:24:39 +0100

Max Kostikov

kostikov@zotum.net

@Tanja That's ok. Here is a big queue on @Zotum due several hubs went offline so messages are sent with delay.

Geonosis Thu, 11 Mar 2021 22:01:42 +0100

Stefan Haydn

sh@hub.hayfidelity.de

@Tanja Yes, I had in mind that in a certain amount of time an old channel gets deleted or as @hEARt PhoniX mentioned above will be marked as „dead“. My hub was deleted about a year ago, so I have thought that would be ok having the same hub/channel combination new installed. Well, It wasn’t. 😁 But I have learned about the mechanisms of the fediverse, so all is fine. 👍🏼

Fri, 12 Mar 2021 10:54:34 +0100 zuletzt bearbeitet: Fri, 12 Mar 2021 11:03:31 +0100

Witcraft (inactive)

witcraft@hub.witcraft.de

I understand that other Fediverse projects would have to find solutions, too, but it seems to be affecting (or have been affecting) quite a few active users, not speaking about confusion for prospective Fediverse hub admins and users...

It somehow worries me that domain and channel names can become permanently unusable in the Fediverse when you fall into situations where you have to re-install them. I am starting to grasp what the statement "will be deleted for good" was supposed to mean when I deleted clones of my channel on other hubs just for a function test - It obviously did not mean "we cannot recover it for you" but "the ID will be banned for eternity on this site"...

I know now how to work around it (find new names whenever something is wrong...), but I think this concept might turn out as a major show-stopper (although insiders obviously find out for themselves and how to work around).

Well, if new long hashs can be detected for blocking delivery out of security reasons - wouldn't it be possible to detect them for notifying about and purging old data (automatically, or at least on confirmation or request)? I know it is not desirable to just sneak in new owners in existing connections - But to my naive mind, it should be possible to purge such old connections to make room for new connectivity when a unique site/ID combination uses other hashes than previously stored.

Fri, 12 Mar 2021 11:05:52 +0100

Max Kostikov

kostikov@zotum.net

@Witcraft
It must be understood that convenience often conflicts with security and privacy. Hubzilla was developed with focusing to the user privacy that's why it works by this way.

wouldn't it be possible to detect them for informing and purging old data (automatically, or at least on confirmation or request)

We can implement anything.
But tell me how it can be prove that it is you, the former owner of the channel, who are trying to regain control over it?

Fri, 12 Mar 2021 11:16:01 +0100

Tanja

tanja@hz.lazyteddy.eu

@Witcraft Zot sites (Hubzilla, Zap, Misty, etc) let you export your channel so that you have a backup which you can import on other instances running the same software. So it should, in theory, be possible, to re-import your old channel if you really have to re-install. Maybe @Max Kostikov can correct me if I'm wrong.

Fri, 12 Mar 2021 11:23:42 +0100 zuletzt bearbeitet: Fri, 12 Mar 2021 11:33:46 +0100

Max Kostikov

kostikov@zotum.net

@Tanja

So it should, in theory, be possible, to re-import your old channel if you really have to re-install. Maybe @Max Kostikov Kostikov can correct me if I'm wrong.

Yes, as I wrote above on channel import / export keys also included in the file so if you have a dump you can restore your data and confirm your channel ownership.

Fri, 12 Mar 2021 11:32:33 +0100

Tanja

tanja@hz.lazyteddy.eu

@Max Kostikov Oh, right. Missed that.

Fri, 12 Mar 2021 11:53:05 +0100 zuletzt bearbeitet: Fri, 12 Mar 2021 11:55:34 +0100

Witcraft (inactive)

witcraft@hub.witcraft.de

I do understand the security problem.
@Max Kostikov

But tell me how it can be prove that it is you, the former owner of the channel, who are trying

my naive idea was: I don't have to - new hash = new channel... Only if someone specifically wants to regain the old channel, there would have to be proof.

But do I understand that right: as long as I use the same clone network or channel export, I can regain my channel short name? So I can clone or export a channel before its deletion, and I can regain the same name on the same subdomain?

Fri, 12 Mar 2021 12:02:14 +0100

Max Kostikov

kostikov@zotum.net

@Witcraft

my naive idea was: I don't have to - new hash = new channel

New channel with the same address and different keys will be considered as forged on other hubs who had connections with your channel in the past.

So I can clone or export a channel before its deletion

Yes.

and I can reugain the same name on the same subdomain

As I wrote above I don't sure if you can reuse channel with the same name on freshly reinstalled hub with the same domain name.

Fri, 12 Mar 2021 13:52:05 +0100

Hilmar R (u-zapalot)

hi-u@zapalot.in-eu.net

@Max Kostikov can you please explain in brief what "channel name" with same address can be? me@url.tld vs url.tld/channel/me both contain the part of an url. Is the domain name or the associated ip relevant for such channel property? I assume it will be the name construct. Otherwise problems will arise in sites with several vhosts. Thx

Fri, 12 Mar 2021 14:07:51 +0100

Max Kostikov

kostikov@zotum.net

@Hilmar R
I did not understand your question.

Fri, 12 Mar 2021 14:44:54 +0100 zuletzt bearbeitet: Fri, 12 Mar 2021 15:49:16 +0100

Witcraft (inactive)

witcraft@hub.witcraft.de

OK, I just tested: At least in my test, it was impossible to clone my channel to a hub where this channel hadprevisouly been cloned to and deleted...

So this essentially seems to mean:

An identity can be created exactly once per site - not only in uniqueness, but also in time. No matter whether it is an independent channel, a channel clone, or (I suppose, too) a channel re-import: If you ever delete it, it will be banned on that site forever - There is no way of bringing it back, unless...
...you happen to own the hub, and intentionally or accidentally "trick the system". If you re-install it from scratch (or take over the domain - which is a valid use case - and install new), then any channel name from this (sub-)domain will be treated as forged by every site that ever had contact to the previous channel owner of the same name. Again, with time limit = eternity. If I register a channel smith@site.org, not knowing that a smith@site.org has existed and archived before anywhere in the Fediverse, I will face serious problems without being signalled why, or even being warned in advance.

If I had to chose between the inconvenience of eternal condemnation ("Treat it as forged") and lack of security ("Trust it"), I would cheat, and chose instead the inconvenience of losing contacts ("Treat it as if it had not existed before").

Just as a disclaimer:

I accept it as is, and I am not making demands here. But I am all for speaking out and pinpointing the consequences of a concept. And AFAIK, the inconvenience accepted will be the above, as trade-off for a security - whose purpose I still do not understand, because I fail to see value in archiving dead channel addresses that will never be admitted to be formally reclaimed by anyone under the same address again (at least by cloning, not sure about channel import).

Fri, 12 Mar 2021 14:54:55 +0100

Max Kostikov

kostikov@zotum.net

@Witcraft

I still do not understand, because I fail to see value in archiving dead channel addresses that will never be admitted to be formally reclaimed by anyone under the same address again

This is for identity protection. Nobody should be able to use or moreover steal other identity by using the same channel address.
And this is one of Hubzilla advantages.

Fri, 12 Mar 2021 16:44:15 +0100 zuletzt bearbeitet: Fri, 12 Mar 2021 16:45:10 +0100

M. Dent

dm42@my.hosted.social

Nobody should be able to use or moreover steal other identity

But the "identity" is not the webbie - that is just a human convenience.  The identity is the guid.  The question is, should a new guid be able to be assigned to previously existing webbie if that webbie is no longer in use?  I see pros/cons on both sides.

Ultimately what convinces me that the current limitation is the correct one is that PEOPLE don't think in terms of guid - that's only for machines. Human beings as they navigate cyberspace "identify" a person by the human readable webbie (user@hub). The cautious approach of not allowing duplication of webbies is the wise approach even if inconvenient.  And there is really no way to test for duplication since the system is fully decentralized.  As a result, hubmins need to be mindful and aware of the challenge.

A possible "best practice" for node operators to help assure DNS uniqueness for all nodes is to always use a hostname and not install on the raw domain name and also add some pseudo-random or otherwise unique element to the node name if it's something generic (hub321.domain.com for a hub installed in March of 2021 for example).  If a somewhat unique hostname is used that is itself unlikely to collide with previous hostnames that others may have used on that domain, then there is also no issue.

Hubmins would also be wise to find a good data source to know what hostnames were used on a previously owned domain before choosing a hostname.  I'm sure Hubzilla is not actually the only software package that suffers from this sort of issue - though - because of its application, it is likely to be more obvious and impactful when it is discovered.

Fri, 12 Mar 2021 16:47:41 +0100

M. Dent

dm42@my.hosted.social

An additional benefit to using a hostname is that it should help reduce (though certainly will not eliminate) the confusion of webbies and email addresses since email addresses typically (though not always) use only the raw domain name.

Fri, 12 Mar 2021 16:57:14 +0100

Max Kostikov

kostikov@zotum.net

@M. Dent

But the "identity" is not the webbie - that is just a human convenience. The identity is the guid.

That's right, I just tried not to go deep into implementation details.

Fri, 12 Mar 2021 20:31:58 +0100 zuletzt bearbeitet: Fri, 12 Mar 2021 20:35:02 +0100

Witcraft (inactive)

witcraft@hub.witcraft.de

@M. Dent
I completely agree that people do not think in guids. But I do not share the consequence you draw from it:

So we have a machine-readible guid (like a db table's primary key), plus a human-identifiable - at a given time unique - webbie (identifier, like a user name or email), plus a non-unique human-readible long name (like a full name / sender name), which is more or less optional...

By asking for a human-identifiable webbie to be unique not at a given point in time, but always, you leave the local management without means to control it. The consequence is manual overhead like the one you displayed (By the way: this would not only require hub admins to manually keep track of and control exclusiveness of names "used up" by encoding it into domains, the next step would be to require channel owners to do the same for their channel names on each hub they are cloned to, leading to minimum webbies like

channel2103@hub2012.domain.org

- which would also change whenever they set up new hubs or import/clone their channel - I would not be so convinced that this is the dimension actually what people think in (neither in use nor in encoded and tracked registration). This pretty much makes the - non-unique! - long name the human-readible handle that people actually remember... (And this is what Email-Spammers actually use, not re-activating old Email accounts).

It is pretty much like asking email admins to encode their Email-Server domains unique in time, and Email-Users to encode their adresses unique in time if they leave and come back - and keep track of it themselves, because otherwise, an email not in use will not be available again, or just not deliver Emails to whole domains who have received one Email from that account before. It is like telling a customer:

No, we cannot create a customer account with an easy-to-remember handle, because we do not reserve primary keys on data tables, only, but also all logins ever associated with any Primary Key - So once accidentally deleted login cannot be created new, because it is not allowed to receive a new primary key. Please encode the current date of time into you login yourself, note that in a place of your desk as "used up login", and then use that in your daily routines. BTW, we synchronize to other places, so we cannot tell you if, before you, someone might have used this specifically encoded handle on our specifically encoded site - So you might be able to register, but your orders with some shops might be ignored, erratically....

Again: Do not get me wrong - If it is like it is, I have to live with it. But I do not have to agree that this convenient, or at least explainable to a regular web user.

And I still do not understand what harm someone can do with a webbie that can clearly automatically be identified as "not the guid one in our archive => unknown" => "new" (as opposed to just "new" - as long as this webbie is simply purged from the archives of all connections who still have it in their archive (for whatever use...). This would just re-set them to the same condition as all other hubs (to whom this webbie actually is new and therefore unidentifiable as a security risk...).

But maybe I just lack insight in the mechanism of the Fediverse. Anyway, for all:
I reflect that I am repeating myself, and I do not want to troll this thread - I just wanted to point out what feels inconsistent to at least me, but I do not envision my opinion as of much relevance to the project. So feel free to leave it at that ("agree to disagree") :-)

Fri, 12 Mar 2021 21:40:07 +0100

M. Dent

dm42@my.hosted.social

@Witcraft

Considering it a bit, I think there are some pieces of code that aren't being considered regarding expiration/marking dead of hubs and some other things that I don't have time to investigate more fully at this time.

I think the general discussion above is correct as to the mechanisms at one level, but I think there are other mechanisms that make the concerns you raise to be a temporary situation. Though - as I said, right now I don't have time to track down all the individual pieces. Perhaps @Mario Vavti knows off the top of his head, or maybe Mike will see and chime in to point us in the right direction.

Tue, 16 Mar 2021 01:13:44 +0100

Stuart Croall

stuart@hz.otherwise.social

It's fascinating the amount of discussion has spawned! It's interesting, but still a bit over my head...

On an immediate, practical level, if I really wanted a channel "stuart" at "otherwise.social" presumably I could spin up a new instance at "hz.otherwise.social" (rather than "hub.otherwise.social"), and that should solve the dead/not-dead channel problem I have?

Along the same lines, if I exported my "souper@hub.otherwise.social" channel, and spun up a hub at hz.otherwise.social, could I then import the "souperate" channel data to a new channel at "stuart@hz.otherwise.social" and carry on with what I've been doing?

I'm still at the testing, experimenting, and learning phase with Hubzilla, so I don't mind changing things up, but I'm hoping to move forward with my primary channel as a kind of "blog" (or at least thinking about it), so settling on a channel name and url might be useful :-)

Tue, 16 Mar 2021 04:19:11 +0100

Tanja

tanja@hz.lazyteddy.eu

@Stuart Croall

On an immediate, practical level, if I really wanted a channel "stuart" at "otherwise.social" presumably I could spin up a new instance at "hz.otherwise.social" (rather than "hub.otherwise.social"), and that should solve the dead/not-dead channel problem I have?

Yes.

Along the same lines, if I exported my "souper@hub.otherwise.social" channel, and spun up a hub at hz.otherwise.social, could I then import the "souperate" channel data to a new channel at "stuart@hz.otherwise.social" and carry on with what I've been doing?

Again, yes.

The way I would do this would be to spin up the second instance while keeping the first one active. You can just use a different name for the database; I have several hubs on the same server, as long as each has its own database, it's fine.
Then, when it's time to create your new channel, you click on "import an existing channel from another location." From there, you can use the second section, "Or provide the old server/hub details" and put in the log in details for the "souperate" channel on the old hub. There is an option to "Use this channel nickname instead of the one provided", where you can put in the desired name, in this case "stuart".

When you're done, on the new hub, enable the "Content Importer" addon in admin and on the channel. Then go to /content_import, adjust the settings (I think you have to put in a starting date) and let it do its magic.

When you're done, you can go to /locs on your new channel and set a new primary location.

Wed, 17 Mar 2021 15:10:32 +0100

Stuart Croall

stuart@hz.otherwise.social

Thanks @Tanja ! That makes a lot of sense, and I'm not sure that, left to my own devices, I wouldn't have inadvertently made things more complicated ;-)

Fri, 19 Mar 2021 17:10:03 +0100

Stuart Croall

https://hz.otherwise.social/channel/stuart

Well, I moved my channel. I ended up exporting the other, and importing the file because, for whatever reason, pulling from the other channel wasn't working. I had my connections (and I reconnected to ActivityPub connections) but I didn't get any of my content, and had no luck importing it through the content importer. From a practical perspective, this is not a big deal because, at this point, I had virtually nothing posted. I'll maybe do some testing on other channels to see if I can figure it out for future reference.

Also, when I went to /locs on either site, only the local channel showed up, and each was set as "primary." I'm assuming this means they aren't actually clones of each other. Which, again, is fine, because my intention is to delete the "souperate" channel at "hub.otherwise.social" and then delete the site... although I guess I could keep it for testing things.