Subj : Re: Worked on this earlier after work this evening... To : mark lewis From : Tony Langdon Date : Wed May 06 2020 04:12 pm -=> On 05-05-20 08:32, mark lewis wrote to Tony Langdon <=- ml> Re: Re: Worked on this earlier after work this evening... ml> By: Tony Langdon to mark lewis on Tue May 05 2020 18:01:00 TL>>> domain fidonet d:\fe\outbound 1 TL>>> domain wwivftn d:\fe\outbound 1 TL>>> domain scinet d:\fe\outbound 1 ml>> yes but then you cannot be in two FTNs that used the same zone and ml>> there are several of those out there... TL> Well that's the problem 5D is supposed to solve, but not all TL> implementations can do that yet. For example, SBBSecho uses a TL> domain to zone mapping that appears to be 1-1, which I'm not sure TL> could handle 2 domains with the same zone. ml> exactly... unless you use the format i linked to earlier (link quoted ml> below)... Umm, how does that help when a tosser has a 1-1 zone-domain mapping? The issue here is in the tosser being able to infer the right zone from what is effectively a 4D addressing scheme internally. I'm specifically thinking of SBBSecho here. the ftndomains.ini file describes zone to domains mappings, but in a true 5D environment, anything's possible, and a truly 5D aware tosser shouldn't assume any relationships between zones and domains, other than being explicitly told the zones for each domain. ml>>>> if your tosser uses the other form of 5D BSO, then the paths can be ml>>>> like you have them but the zones all have to be 1 so the directories ml>>>> get the hex extension added to them... TL>>> This is for BSO format that both SBBSecho and Mystic (mutil) use. ml>> if i'm reading this correctly, then yes... see here for the (almost) ml> current domain setup my binkd is using to work with sbbsecho... ml>> https://paste.linux-help.org/view/07b043b2 TL> Yep that's what I'm talking about. :) ml> yes, it is part of my work on trying to see what is necessary for ml> sbbsecho to be fully 5D complient... there are some problems due to ml> some 4D assumptions but they are easily worked around... i just need to ml> find more time to dig deeper into the code and see what fixes are ml> needed... The question here is what do you see SBBSecho needs? To me, it looks like SBBSecho is actually 4D internally, and a simple translation table is used to map zones to domains, but there's an obvious flaw - if two domains have the same zone, how does SBBSecho know what is what? Anyway, my binkd config is a smaller version of that - using the domains I am connected to, and a default zone of 3, rather than 1. ml>> i need to move it to a git repo, though... then i can more easily ml>> work with updates to it but there's only been one update, a dns ml>> lookup entry for one net, since i put it up... TL> So all of those nets are active? ml> i don't know... the list is gleaned from my mailers' logs by scanning ml> for the FTN addresses and domains presented by other mailers when we ml> connect... that data is then run through a series of linux tools to Reason I'm asking is there's some not in NuSkooler's Google sheet, so looks like someone will need to update the sheet. :) ml> trim it down and create a raw list... that raw list is then manually ml> tweaked into the final result currently being used by my binkd... that ml> raw list is also used to create the proper 5D domain directories in my ml> base BSO directory... i've also added the gathered domains and zones to ml> my tosser's configuration using its defined ini format so BinkIt.js ml> should also be using them when i use BinkIt.js as my mailer... Well, you won't get all the domains I'm connected to anymore, I now have so many AKAs that I have to use hide-aka and present-aka judiciously to make sure my links work! :) ml> )\/(ark ml> --- SBBSecho 3.11-Linux ml> * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12) .... Look closely at the most embarrassing details and amplify them === MultiMail/Win v0.51 --- SBBSecho 3.10-Linux * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410) .