Bug 202401211021 channel deletion import export failure

Sun, 21 Jan 2024 11:37:51 +0100

adminsforum@hubzilla.org

od wrote the following post Sun, 21 Jan 2024 11:37:50 +0100

Bug 202401211021 channel deletion import export failure

A channel was exported.
After activation of activitypub, diaspora, modules, system broke.
Review of server showed logs consumed entire virtual private server allocation, more than 19 gb
Deleted and restarted hubzilla with success
Import of channel failed
Deleted channel
Attempted to create new channel, same name, server response that not possible as channel name exists
In administrator account for hubzilla server, 'admin' side bar list 'channels' does not show the channel name
In the postgresq table 'channel', the channel name exists. Deleted via postgresql command 'DELETE FROM channel_name WHERE channel_name='thechannelnamethatshouldbedeletedbutisnot';

show all 5 comments

Sun, 21 Jan 2024 12:43:31 +0100

Harald Eilertsen

harald@hub.volse.no

Attempted to create new channel, same name, server response that not possible as channel name exists

This is a security feature. To prevent other people to hijack the channel name of a previously deleted channel, and impersonating the previous owner.

It should be documented, though...

In the postgresq table 'channel', the channel name exists. Deleted via postgresql command 'DELETE FROM channel_name WHERE channel_name='thechannelnamethatshouldbedeletedbutisnot';

I suspect there will be other tables referring to the channel as well, so this could cause some issues. (But I'm not sure, let us know if it works well for you!)

Sun, 21 Jan 2024 14:13:04 +0100

_jayrope

jrp@hub.kliklak.net

@Harald Eilertsen I went through this with 8.4. Was no fun, took forever to find all the bits, and obviously I didn't because ultimately I couldn't make it work. A compliment to the security, if you want so. But I had to get a new hub up on a new URL to be able to use my user name again.

Thu, 25 Jan 2024 13:47:55 +0100

Harald Eilertsen

harald@hub.volse.no

@_jayrope I can definitely see there are situations where you would want to wipe a channel completely and reuse it's name, but I'm not sure how that would play with hubs you have already federated with.

Someone who knows the protocol side of things better than me may be able to say whether it would work or not, though.

Thu, 25 Jan 2024 14:55:15 +0100 last edited: Thu, 25 Jan 2024 15:03:08 +0100

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen

I can definitely see there are situations where you would want to wipe a channel completely and reuse it's name, but I'm not sure how that would play with hubs you have already federated with.

Someone who knows the protocol side of things better than me may be able to say whether it would work or not, though.

Many of the legacy platforms allowed a username to be reused after a certain time period, such as 6 month. We could even make that shorter if we want.

With the fediverse, we could implement something similar by specifying that a record about a channel is stale if it is too old. And if a new channel is created with the same address but a different key, it would be considered a different channel than the previous one found at that address.

For those who are technical, it could work similar to "Time to Live" (TTL) for domain names. After a certain time period, the information is considered stale and must be queried from the server again to make sure it has not changed.

So, it could be implemented, but it would require a change in the protocol and how Hubzilla and Streams manages identities.

Thu, 25 Jan 2024 15:35:20 +0100 last edited: Thu, 25 Jan 2024 15:36:48 +0100

Scott M. Stolz

scott@loves.tech

The biggest issue is that the above method only works with Zot and Nomad protocols because those protocols use keys to identify channels. It would not work with ActivityPub because ActivityPub identifies channels based on URL.

There are some proposals related to identity proofs and nomadic identity, but there would need to be changes to ActivityPub for ActivityPub clients to recognize that this is a new channel and not the same as the old channel.

There is a possible work around for this. The old channel and the new channel could give ActivityPub different URLs. For example, instead of https://example.com/channel/demo it would be https://example.com/channel/demo/1 or something like that.

This new URL would be given to ActivityPub so it knows that it is a different channel, but if you visited the old URL in the browser, it would still show the new channel.

But, Hubzilla or Streams would need to know that there used to be an old version of the channel at that address for that to work. If you reinstall Hubzilla or Streams, it would not know that. This could be a feature or a problem, depending on whether the new version of the channel is owned by someone else or not.

So the whole thing gets tricky, since ActivityPub does not use keys.