Re: Linked RLOGIN server.
By: KK4QBN to on Tue Jan 17 2017 18:09:48

What do the SyncOps who run 3.17 and the new ecweb4 (don't even really

I would leave web stuff out of the discussion, though it could become relevant.

need it, Think about a NETWORKED RLOGIN game sharing network, Each board

I imagine you're aware of BBSLink and DoorParty, etc. and you're talking about something more distributed. Rather than one central gaming server, you want a user on one BBS to be able to connect to any other, correct?

so players who opt in to the InterBBS rlogin will have their account info

Per user opt-in would be important. Even if you're just exporting minimal data about them, they ought to be told where it's going, how it's going to be used.

I'm not wild about shipping user data all over the place. Many years ago and on a very small scale (a few trusted systems) we did something similar and I had many reservations about it until I came up with an alternative.

sent to all systems in the network, and they would be able to access anyallowed game on any BBS in that network.

Authentication would be the biggest challenge. The user's password should never be transferred; on the remote system it should be something random. The important thing is that the two BBSs have some way to establish trust. There are ways to do that of course, but they would involve either a central server or a distributed list (of systems, rather than users; a nodelist essentially).

Of course that makes me think of other problems. Username collisions. Systems being offline. Who gets to host which game for the network, or will you have 100 menu entries for playing LORD on this or that BBS? Not that I'm trying to shoot it down, this would just be the next set of questions.

(Central gaming services do a lot of what you're looking for, in a simpler way.
There's the benefit of concentrating a bunch of users in one place for more activity, in theory. If the operator is responsive and cares about their service, there should be no shortage of games or trouble getting them added by request.)

---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
* Synchronet * electronic chicken bbs - bbs.electronicchicken.com
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Linked RLOGIN server.
By: echicken to KK4QBN on Tue Jan 17 2017 07:33 pm

I would leave web stuff out of the discussion, though it could become relevant.

I understand, but if the terminal side can be done, it should'nt be hard to do the web side either (I'm going to try to play with some ideas) I'll probably end up scrwing up royally.

I imagine you're aware of BBSLink and DoorParty, etc. and you're talking about something more distributed. Rather than one central gaming server, you want a user on one BBS to be able to connect to any other, correct?

BBSlink, Doorparty? Nope.. neither one... these came about on my Hiatus I presume.

And yes, No central gaming server, every BBS would have the "Networked Games" page, or application in terminal mode, which would pull up any game offered up by any BBS participating in the program, No central server, Just a central database of systems/games/users. and maybe even other systems can come in as a mirror or backup if one goes down, or something splits.

Per user opt-in would be important. Even if you're just exporting minimal data about them, they ought to be told where it's going, how it's going to be used.

Yes, it would'nt work without per user express consent, the would be told that ANY sysop on the network would have access to their username/pw info and other minimal data, even though it could be possible to have the app to create a password for each system and the user not even have to go through that, user just creates a username, "or uses the one on the system they are on" then the app creates a password for each system on the network and automagically creates their userdata through a networked data sub, or other database method.. JSON? I don't know enough about it. Maybe I need to start reading more into what you guys ALREADY have for us here. because back in the day, I created a way to register a username/etc when the first web interface came out by duct taping batchfiles, along with the little JS I knew, some Baja, and some of the binaries in the exec dir, this was all for my RLOGIN server I ran as a central server for all the linux, etc BBS systems that could'nt have their own doors (before dosemu, doscmd support was put into the code) and JS games were really nothing to be heard of. wish I had backup copies of that old rigged up peice of crap, but it got a LOT of use at the time and served a good 20 BBS systems.

I'm not wild about shipping user data all over the place. Many years ago and on a very small scale (a few trusted systems) we did something similar and I had many reservations about it until I came up with an alternative.

I can understand your concern, especially with some of the infighting we get from sysops.. (including me of course) BUT if the app could create its own passwords, and keep them from EVERYONE, all that would be out there is username, sex, and possibly birthdate. An I figured you would already have some sort of alternative. JSON?

Authentication would be the biggest challenge. The user's password should never be transferred; on the remote system it should be something random. The important thing is that the two BBSs have some way to establish trust. There are ways to do that of course, but they would involve either a central server or a distributed list (of systems, rather than users; a nodelist essentially).

See above comments, Maybe its too much trouble than its worth, but with the way you have incorporated the RLOGIN into the web like this, it has just opened my eyes to what can be done, and I'm very excited again. it's given me that drive to want to dig into the code again and start learning everything as much as possible. there have been MANY changes since I had my last BBS running. all for the good!

Of course that makes me think of other problems. Username collisions. Systems being offline. Who gets to host which game for the network, or will you have 100 menu entries for playing LORD on this or that BBS? Not that I'm trying to shoot it down, this would just be the next set of questions.

Well, I had mentioned on up in the page redunduncy can be bult in, I'm sure, and well 100 LORD entries seem excessive, but I guess they could be listed per game, but I was thinking more on the line of listing per system, or maybe by search string. and all LORDS, TEOS, BRE, and TW2002, etc are not the same. the Sysop who is registering with the system would have the responsability of listing stats for the game, and they don't have to install all games, like all of yours for example, already have networked scores. so maybe those games will run from YOUR system only, and other JS games with the same type of scoring system, etc that have been devoloped by someone else can be hosted bu them only. maybe its a little too excessive. but just an Idea, and one that sounds kind of fun and feasable, there are some fanatics out there who hold true to their favorite games (LORD) for example, thy can scan the database of all LORD games, and details for that game, like FF per day, starting money, IGMS, etc..

Yeah, gets pretty deep when you look at the larger picture :)

(Central gaming services do a lot of what you're looking for, in a simpler way.
There's the benefit of concentrating a bunch of users in one place for more activity, in theory. If the operator is responsive and cares about their service, there should be no shortage of games or trouble getting them added by request.)

Again, Correct, the RLOGIN server I ran was very successful until my whole system was taken out when a Tornado and thunderstorms hit the area, it FRIED my rlogin computer, so EVERYTHING was lost. someone (I wish I can remember who it was) was nice enough to donate equiptment to get it back up, and even shipped it to me for free, but it was'nt enough to get it all back the way it was, I could'nt get the users back, and I ended up shutting it ALL down. thats the only reason I don't like centralized systems. and YES, I had backups, but by the time I was able to get it all back together it was too late. traffic dropped to 1 to 2 users calling when, it would get up to 100 or more daily. Just on the RLOGIN server machine, then I did FTN/QWK <> Gateways on my BSD system and had much traffic on it too, and it all went to hell also..

Thats just why I wish for something not so centralized.

Thanks for your very informative answers. it's taking me a bit to get back what I've lost when I stopped using the system daily (JS, BAJA, even submitting a correct bug report) but daily I think I'm getting better.

--

Tim Smith (KK4QBN)
KK4QBN BBS

... It is not enough to succeed. Others must fail.

---
* Synchronet * KK4QBN BBS - (706)422-9538 - kk4qbn.synchro.net, Chatsworth GA US
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Linked RLOGIN server.
By: KK4QBN to echicken on Tue Jan 17 2017 21:22:40

the way you have incorporated the RLOGIN into the web like this, it has just opened my eyes to what can be done, and I'm very excited again. it's

Doing this on the web or on a central gaming server is pretty straightforward. Some inspiration could be taken from those designs, but there will be unique problems in a distributed system. I have a rough picture of how I might do it if I were designing such a thing.

some sort of alternative. JSON?

So, JSON just means JavaScript Object Notation.

For Synchronet we have the JSON-DB service, which stores, transmits, and receives stuff as JSON strings. Unfortunately it's just called 'JSON' by default in services.ini, which muddles things a bit. JSON is used in lots of places, but the JSON-DB service is part of our little world here.

If you think you need a central database, or for each system to expose a database, then JSON-DB could be useful. I'm not sure if it would have a role.

get from sysops.. (including me of course) BUT if the app could create its own passwords, and keep them from EVERYONE, all that would be out there is

The next question is what the app is/does and what it needs passwords for.

For a user to connect and play a game on someone's BBS, they need to be logged in. If they're logged in as a real user, everything's simple. If they're logged in as a guest but you want them to have a unique identity in the game, then you probably need to start that game with a launcher that fudges dropfiles. The former case wouldn't work for all games.

Just a central database of systems/games/users. and maybe even other

I would suggest a distributed list of systems and games, but not users. The users are mostly relevant when they want to connect, and minimal data can be exchanged at that point. Unless the BBS has some means of authenticating a user against an external source, there's not much point in giving that user a record or a password in your database. (I may not yet be understanding how you envision this working, though.)

systems can come in as a mirror or backup if one goes down, or something

So, that's a nice idea and something that various centralized services ought to consider. Would be a benefit of a distributed system, though keeping things synchronized could be a pain.

Anyway, it's an interesting idea. Keep on brainstorming. I've got plenty of opinions, and they're not necessarily correct - but it's fun to chat about.

---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
* Synchronet * electronic chicken bbs - bbs.electronicchicken.com
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Linked RLOGIN server.
By: echicken to KK4QBN on Tue Jan 17 2017 11:07 pm

Anyway, it's an interesting idea. Keep on brainstorming. I've got plenty of opinions, and they're not necessarily correct - but it's fun to chat about.

Yes it is, and I'm endevouring to become efficent in JS, mainly from the projects you have worked on, and the fact I like to tinker with stuff thats out of the norm. It seems when I know how to code something, I get a "writers block" and cannot think of any decent Ideas. and When I get a good Idea rolling in my head I am too ignorant too code it :-) sure its all in time. once I get used to all the new features.. You explained exactly what Json is and it's uses for SBBS, until I got back into BBSING, I did'nt know one thing about it, or even that sites like GITHUB existed. I have so much I want to learn, and not enough time to do it..

Most of the free time I get to mess around is when I'm awake because another bout with insomnia, knodding off at the keyboard, and most of the time forgetting what I have done the night before. I blame a lot of that on things I indulged in in the past. but that is just it, the past. maybe I can actually overcome a lot of the barriers I would get trying to learn code because I was chemically impaired in one way or the other :-)

--

Tim Smith (KK4QBN)
KK4QBN BBS

---
* Synchronet * KK4QBN BBS - (706)422-9538 - kk4qbn.synchro.net, Chatsworth GA US
* Origin: Vertrauen - vert.synchro.net (1:103/705)