I created a network
I created a channel
I joined another system to the channel.
I gave channel root key to my remote system
The channel split.

Some users stayed in one side with me, other users followed the co-owner to the other side. It reminded me of the old IRC days, when the net split and the users were divided.

I am not sure yet what keeps a channel open and functioning. I hope it will not require the 'host' owner to be online, like in the old winMX days. Back then if the channel host's computer froze or crashed, the channel would break up.

The idea of multiple owners is useful.

For this single host issue, I'd suggest again what I suggested 15 years ago for winMX...have standby hosts. If the primary host falls offline, a backup host is called into service instantly.

Again, this is all new to me, so maybe if we have channel managers/OPs that will keep the channel from collapsing when the host/owner goes offline, great. Works well on tixati and better on fopnu. Just not sure how this new-fangled DarkMX will behave.

back to testing...

Reviving this old but yet unanswered topic. I have more questions related to ownership, sorry for the thread hijacking. If I may...

At the time we are on v1.32.

1. Can different owners have Host mode On at the same time, what that does? Rough load balancing, random splitting of connections as OP observed, or none of those and just unacceptable state?

2. As was stated somewhere the owner doesn't have to be online as long as at least one of moderators or higher level users is online/connected. But if that is correct to maintain the ability to join a network or channel, presumably that would affect file sharing. But again, the current scheme of sharing glues a user to his file shares, so the best would be assigning a moderator to a node that is keeping network and channels, with no or only lightweight common file sharing ("Share" group only)?

3. Also, from a physical security point of view, keeping a large file shares does not require to keep the network/channel private key on the machine. Normal user level on 'a server' will be sufficient thus desirable to protect the network/channel from hijacking by exporting a private key from such a cracked node. Is that right and preferred policy?

4. Related question: how to transfer hosting of network/channel to another owner so the ex-owner will lost the actual key/ownership and the key will be deleted/purged from ex's machine? Will that supposed to work ONLY by agreement that ex will set his Host OFF, then the new owner regenerates a new private key? Will the subscribed users remain preserved in such a transition?

5. Are groups made for local machine access control and exclusively for owners? Meaning each owner has its own private set of case insensitively named groups? Or if owners have shared object of ownership (network or channel) their lists of groups must have common parts and group names have to match? Just trying to figure out common use cases for naming groups unless their scope limited only to the local node/machine.

6. The "Share" named group is presumably the group for public default sharing and has to be disabled to become unlisted for a file share that associated with any other group to have any meaning as it's logical OR access control operation?

That post was a very early test when darkMX was just released.
There cannot be more than one simultaneous active host.


Tixati and fopnu work that way, not darkMX.


User share libraries and channel ownership/control are not related functions. A channel owner/host client might not have any shared files, or might have a million.



As the notification says, use caution when sharing the root key because it is the key to the kingdom. But actually the users are in control. Anyone can create a root key and advertise it. But if no other user decides to join, then there is no channel. It takes at least 2 users to connect to make a channel. If an owner decides to share the root key with another, and they later have a falling out and can't cooperate, and both remain set as host, then the channel will split. But in that situation, the users have no control that I am aware of to select which owner they want to remain connected to. One owner will have to create a new root key, advertise it and the users will then decide if they want to connect to that owner's new channel. In effect, users are in control. They can't be forced to join any channel. It is only by user consent.

3. Yes, although the functions aren't related they do influence on a node security practices. Coupled with answer from #2 that would mean a DarkMX network/channel owner has to remain online while file sharing node that run under Normal user level should obviously do the same. That way a raid on file sharing host won't affect the security of the network/channel as the root key isn't there. Meaning we need at least TWO machines connected 24/7.

4. It remains unclear to me what happens when the channel root key has been changed. But its onion public address remains. So how to distinguish it from the one with the old root key? Or the old key remains serving that onion address unless host mode is switched off?

5. ?

6. ?