Subj : Re: This vs That - taking the pulse. To : Oli From : Avon Date : Mon Dec 02 2019 12:42:14 On 01 Dec 2019 at 06:19p, Oli pondered and said... Ol> A> At the heart of this discussion are a few things/points/questions you Ol> A> are raising. Here's my take on what those are. Ol> Ol> A> - what things are being done now that are (for want of a better term) Ol> A> network related admin that could be done not just by me but by Ol> A> others? Ol> Ol> Is there anything that can't be done by others? Answering a question with a question bakes my brain :) If we could talk specifics that would enable me (at least) to give a more informed reply. Ol> Then you are the first contact for new nodes. It seems that you are Ol> spending quite some time in helping people to setup their BBS / FTN Ol> connectivity. I am first point of contact for a node application at the moment yes, but then allocation of a node number, and setup / liaison with the node is handed off to the HUB admin. I do spend time helping others, often it can be someone who has been a member of this network or an othernet for quite some time and then something comes up and they ask for help. I mention this as it's not like all my 'helping others' efforts are based around brand new nodes these days. That 'helping others' stuff ebbs and flows also.. hard to predict when it will occur. Ol> A> - is this happening now in any shape/form? Ol> Ol> I don't believe so, but I'm not sure. Hopefully the above info / reply will help clarify :) Ol> The most important task is updating and distributing the nodelist. [snip] Ol> I don't see any reason why the nodelist cannot be updated Ol> collaboratively. E.g. use a private SVN / Git / Mercurial / Fossil Ol> repository and give every network write access. If we were to run with the established practices of NETs supplying a nodelist segment for compilation into a nodelist then this may address your comments about collaboration in this area? Is it needed - unsure. Could it be done - yep. I do have some ideas around decentralized nodelist management but it would take some dev work to implement them. Ol> A> - what does an acceptable level of service look like for all this Ol> A> stuff? Ol> Ol> Level 8 would be nice ;) I'm not an IT person by trade but I'm guessing this good - right? :) Ol> A> - are we trying to fix something that is viewed as not broken, or is Ol> A> it broken? (I may be a bit harsh in my terminology using broken but Ol> A> you get the idea) Ol> Ol> At the moment it is bus factor 1-ish, but as long as Avon is not broken Ol> and keeps updating the nodelist, I wouldn't call it broken. It depends Ol> on the criteria you have. If the criteria were scalability and Ol> fault-tolerance, you could call the current process broken. On the other Ol> hand, even if Avon would shutdown all his nodes without any warning, the Ol> network would not cease to exist. I don't think anything is really broken either. I think if it were then new nodes would not be coming in / others coming off. Chatter in the ehcos would be nil etc.. and that's plainly not the case right now... so if broken were to be the absence of activity etc.. then yep, were *not* broken :) That all said, there will be different, probably better ways to do things, but all dependent on what is agreed success / ideal state looks like. I can't help but think we should be kicking that topic around some more and fleshing out that bit first before jumping to solutions. My 2 cents.. Ol> @Alterego: I'm not sure if fsxnet should be seen as the successor to Ol> Fidonet. Maybe it would also make sense to start a new Fidonet in a Ol> truly decentralized and collaborative fashion? I'm more than happy for fsxNet to take the lead in experimenting with approaches to decentralization and collaboration. It's really an area of interest to me and others. I also am keen on how we can better implement encrypted mesh networking ideas into this discussion. But to do so we need agreement on what that means by all involved. I think I may have already said that :) --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32) * Origin: fsxNet HUB (21:1/100) .