Deleting channels?

2024-10-13 15:38:11

adminsforum@hubzilla.org

dynamic_hubzilla schrieb den folgenden Beitrag Sun, 13 Oct 2024 15:38:10 +0200

Deleting channels?

Is there any way to delete channels?

I previously set up several channels for myself to test things out, but right now they mostly feel like unnecessary clutter.

2024-10-13 15:41:45

Harald Eilertsen

harald@hub.volse.no

@dynamic_hubzilla Sure. Just go to the settings of the channel you want to delete, and then click the big red button in the top right corner :)

2024-10-13 15:43:54

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

Be careful, though: Once you've deleted a channel, nobody, not even yourself, can ever create a channel with this name on this hub ever again.

So if you think, "I don't need this channel right now, I'mma delete it, maybe I'll make a new one with the same name when I feel like it": No can do.

2024-10-13 17:35:37

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@dynamic_hubzilla

Once you've deleted a channel, nobody, not even yourself, can ever create a channel with this name on this hub ever again.

It is quite possible to recreate a channel with the same name. However, YOU must contact the administrator of the hub and ask them to delete the old channel name from the database. This does not involve any work.

---
Sent by a #Hubzilla instance to the #Fediverse

2024-11-07 22:59:58

od@zotum.net

@Rogue Runner
@Scott M. Stolz

Thė suggestions about keys seem great: how to create an environment for new programmers to join the project and write such vital feature?

2024-11-09 12:16:06

Scott's Code Journal

scott@codejournal.dev

@od I suppose the first step would be discussing it with @Mario Vavti and coming up with a plan on how to implement it.

This discussion came up several times before, and it is something that could be addressed, although with some caveats. I am not sure how much work it would take to make it happen though.

https://hubzilla.org/display/b64.aHR0cHM6Ly96b3RhZGVsLm5ldC9pdGVtL2QyNjY0ZTIxLTAyZGMtNDU1MC1iOGE3LTMxMTE4OTQyZGViMg

https://socialhub.activitypub.rocks/t/reuse-of-identity-channel-addresses-revocation-reissue-of-keys/2888

2024-11-09 14:31:30

od@zotum.net

Nomadic identity cannot work if security keys are _not_ mandatory.

2024-11-09 21:39:45

Rogue Runner

cisco@inlakech.site

@od
@Scott M. Stolz

Forcing to put your master/private key onto your own device upon install would make you able to prove your ID in case of a server meltdown or accidental loss of your master ID on the server. You would always have a master on your device to start over.

2024-11-12 08:29:40

Scott M. Stolz

scott@loves.tech

@Rogue Runner You can already download your JSON file with your key and everything necessary for recreating your account on another server. So you can do that now, it just is not mandatory.

2024-11-12 20:50:16

Rogue Runner

cisco@inlakech.site

@Scott M. Stolz ... That was why i used the word 'forcing' upon install, which would make it mandatory to backup your master/private key to your own device. Or an option to bypass this backup at your own risk.

But i was more leaning towards the key manager idea that could issue or revoke keys for the same channel to be used with a new ID and same actor.

2024-11-12 21:16:01

Scott M. Stolz

scott@loves.tech

@Rogue Runner I doubt a less tech savvy person would understand the concept of keys much less how to use one. Forcing people who are not tech savvy to do things they don't understand is a recipe for disaster. And it's akin to having them write their password on a post it note on their monitor. Anyone who has access to their unsecured computer has access to their identity. It would be less secure, not more, in that scenario.

So forcing people would not be a good idea.

But I do agree with the idea of issuing and revoking keys. I brought up the topic before.

2024-11-12 22:15:36

Rogue Runner

cisco@inlakech.site

@Scott M. Stolz ... Fair enough that it might be over the heads of the none tech savvy... which is why having the option to bypass that part of the install would be there. One would think though that if you are at a level of installing a new hub on your own server, that you would be confident enough in knowing what the process is all about. And you would also know how to encrypt a file or at least put it into an encrypted folder. The process could be explained in the install document.

I did see your posts about implementing the revoking and issuing of keys from posts that are a couple years old... i have not seen any follow up on those ideas. Is there a reason for not having this implemented..?

2024-11-13 05:55:51

Scott M. Stolz

scott@loves.tech

@Rogue Runner

I did see your posts about implementing the revoking and issuing of keys from posts that are a couple years old... i have not seen any follow up on those ideas. Is there a reason for not having this implemented..?

Not enough resources, and other things have more priority.

2024-11-13 05:57:14

Scott M. Stolz

scott@loves.tech

@Rogue Runner

One would think though that if you are at a level of installing a new hub on your own server, that you would be confident enough in knowing what the process is all about.

There are several public hubs that anyone's grandma could sign up for. And I plan on launching some more. You don't have to run your own hub to use Hubzilla.

2024-11-14 03:28:12

Rogue Runner

cisco@inlakech.site

@Scott M. Stolz

There are several public hubs that anyone's grandma could sign up for.

To all the grandma's out there that want to take Hubzilla for a test run... I salute you ! May the road rise with you, because the river is deep and the mountain high.

2024-11-14 03:47:27

Rogue Runner

cisco@inlakech.site

@Scott M. Stolz

You don't have to run your own hub to use Hubzilla.

That is true, however key management should be left to the admin, and not to the regular user.

2024-11-14 05:02:31

Scott M. Stolz

scott@loves.tech

@Rogue Runner Hubzilla has two sets of keys. The server itself has a set of keys to identify itself, and each user has a set of keys for themselves.

Right now there is no way for an admin to change the server keys and not mess things up for existing channel names. Same applies for the user, except it would just mess up their channel.

Users already have access to their own keys. They can download them and then use it to clone their channel on another server. Since most people are not tech savvy, we don't refer to it as keys. But the reality is, they have possession of the keys if they download that file. And they are transferring their key pair to another server by cloning their account.

2024-11-15 20:24:08

od@zotum.net

@Scott M. Stolz

Right now there is no way for an admin to change the server keys and not mess things up for existing channel names.

This is a major weakness for future exploitation by bad and/or incompetent actors with access to a web server.

2024-11-19 05:35:01

Rogue Runner

cisco@inlakech.site

@Scott M. Stolz

Right now there is no way for an admin to change the server keys and not mess things up for existing channel names. Same applies for the user, except it would just mess up their channel.

My understanding is that the Zot/Nomad protocol can handle all the things discussed on this thread. But there was a deliberate clipping, or handicapping of the code to not allow re-use of channels... this was to be in line with, or compatible with, the rest of the fediverse.

The Zot/Nomad network does not need a specific server ID, as it is server independent. It does not care what server your using, it just needs your guid/private key hash.

On the other hand AP (activity pub) protocol 'does' need a specific server ID. This difference is why Zot/Nomad can introduce a security hole in these other networks... as it would become fairly easy to spoof channels on the other networks.

Having to handicap your code to suit other networks is unfortunate... the Zot/Nomad protocol seems to be ahead of the game, and just waiting for the rest to catch up.

2024-11-19 15:50:55

Scott's Code Journal

scott@codejournal.dev

@Rogue Runner If you take control a domain name (perhaps by purchasing an expired domain), you can spoof any account that was previously on that domain by installing Mastodon or something similar, since they have no keys.

Hubzilla preventing you from reusing channels is not going to change that. I don't see any security advantage for removing that feature. There are so many ways around it, you could drive a bus through it.

2024-11-19 15:52:07

Scott's Code Journal

scott@codejournal.dev

@Rogue Runner I could see where you may not want the user to take over previously used channels. However, the admin should have the ability to do so.

2024-11-20 05:16:40

Rogue Runner

cisco@inlakech.site

@Scott's Code Journal ... The ability to re-key/re-use is at the heart of this dilemma so it seems. To allow or not to allow..? At the moment nobody is allowed... unless you hack your database. Fediverse will not allow... but Hubzilla is capable.

2024-11-20 05:43:13

Scott M. Stolz

scott@loves.tech

@Rogue Runner That about sums it up.

Currently, it is a hassle for admins moving to another server. But there are legitimate concerns about a new user taking over a channel address, mostly because other platforms don't support keys.

2024-11-20 11:34:58

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@Rogue Runner

but Hubzilla is capable.

...which may not be easy to carry out, but which is useful.

One big side-effect of blocking used identities is that every botched clone leaves scorched earth behind. Whenever a cloning process was mostly unsuccessful, but still actually created a (useless) clone, not only can't you create a new clone with the same name, but you can't clone the same channel onto that hub anymore, not even under a new shortname. If the issue is on the side of your main instance, and you don't know, you burn through hubs, and you may end up with nowhere to clone.

This is something that hubmins can mitigate by manually removing the records of your channel from their hub so you can try again.

2024-11-14 05:04:54

Scott M. Stolz

scott@loves.tech

@Rogue Runner

That is true, however key management should be left to the admin, and not to the regular user.

That may be a reasonable approach. We take that same approach with web hosting. The web host client can do certain things themselves, but for more advanced features they have to contact technical support and we do it for them. There are pros and cons to this approach.

2024-11-15 20:25:19

od@zotum.net

@Rogue Runner

One would think though that if you are at a level of installing a new hub on your own server, that you would be confident enough in knowing what the process is all about

Since this cannot be guaranteed, the software security has to be more robust

2024-11-15 20:27:28

od@zotum.net

@Scott M. Stolz

Forcing people who are not tech savvy to do things they don't understand is a recipe for disaster.

See matrix. Account creation forces new users to verify either by _second_ password or verification key. Works well.

2024-11-20 07:51:58

Ema エマ

ema@utasansh.in

When moving to another server, you‘ll have to copy over the database. @K&T Host helped me the last time doing it, and before that, it was @elmussol who helped me.
I think before doing it, you should go offline with your old server, and only when things are done, you should go online with the new server.

2024-11-21 14:27:05

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

With phpMyAdmin it's a piece of cake.

2024-12-01 17:07:36

Rogue Runner

cisco@inlakech.site

Why not issue a duplicate channel key to the admin every time a new channel is created on the server... these keys would be permanent and also delete-able. The user channel keys on the other hand would be time stamped and expire after a period of time... but some days or weeks prior to expiry, a warning to the user is issued to renew your key... if the key is not renewed by the user, the admin will have the option to renew, re-assign a new server, or delete the keys.

A modified version of guest access app could be used... except it would be modified for admin use only as key/token manager. That way a built in or addon UI would be possible for the admin to manage all the server keys.