• New BBS Tech

    From Smooth@46:1/183 to All on Sun May 7 02:19:59 2017
    What I do see a need for is the implementation of new BBS Tech. Especially in areas of Message Base format and Door Game development. JAM has been the
    most popular format for bbs messages areas for ages. I'm surprised that no
    one has tried to migrate it over to a SQL or NO-SQL type data repository
    (JSON formatted data). Maybe it's to difficult a task to do so? Not sure but
    I find that it would totally open up many possibilities for doing some hybrid telnet/web systems.

    Door Game development on Mystic Boards have grown quite a bit with MPL
    language and the use of Python to extend features outside of the BBS box. Totally dig that. I'm wondering what other BBS softwares out there have
    native door dev support like Mystic. It'd be nice to see some competing
    techs. Totally makes it a competitive playing ground for existing bbs mod groups.

    It'd be awesome to get ideas from sysops too what they would like to see as
    far as new doors (utility/games), bbs software, and bbs mods.

    |10Smooth|07<|11ACiD|08.|11b7|07>

    --- Mystic BBS v1.12 A31 (Windows)
    * Origin: .{* iNK!2 // bbs.inktwo.com \\ agoranet *}. (46:1/183)
  • From NuSkooler@46:1/173 to Smooth on Tue May 9 22:09:11 2017


    On Sunday, May 7th Smooth muttered...
    What I do see a need for is the implementation of new BBS Tech.

    I have on my list -- and a lot of notes around it -- plans to experiment with a
    fully end-to-end encrypted (e2ee) and decentralized (e.g. no central server dependency) message network for BBS's and whatever else wants to use them. The underlying payload portion of the protocol would be JSON.

    ENiGMA 1/2 BBS uses SQLite for message storage, file bases, user bases, and so on. JAM is not yet supported, but FTN/bink style is: This is treated as an "external" format. In other words, natively it's always database driven but seamless import/export FTN. JAM and any other format can be added the same way by implementing the external handler.

    As for doors, ENiGMA can run JavaScript (Node.js) based doors - just write one.
    Synchronet (though it handles it quite differently) can do the same AFAIK. At some point I plan on writing some door stuff -- and will probably create a small JS based door kit. node-blessed would be a good start here.

    A JSON dropfile would be slick too -- and I've love to see people stop doing socket fd sharing (e.g. door32.sys) as it too much relies on the *door* doing socket I/O which IMO it would be abstracted from.



    --- ENiGMA 1/2 v0.0.5-alpha (linux; x64; 6.9.5)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (46:1/173)
  • From Smooth@46:1/183 to NuSkooler on Tue May 9 22:34:42 2017
    On 05/09/17, NuSkooler inked down this thought...
    I have on my list -- and a lot of notes around it -- plans to experiment with a fully end-to-end encrypted (e2ee) and decentralized (e.g. no central server dependency) message network for BBS's and whatever else wants to use them. The underlying payload portion of the protocol would
    be JSON.

    I've been thinking of setting something like that up with MongoDB. Data
    should be saved in JSON format in the current day. JAM/Squish are old
    formats. Having it in JSON would make it easier to integrate to
    the web or native mobile apps. There would be no need for polling if everything was synched up to a specific endpoint. BBSes would just have to subscribe to echoes and read/post messages to and from a web service
    (RESTAPI). We'd just have to generate access tokens for someone to connect
    to the web services. There would be no scheduled downtime for polling/tossing mail.

    As for doors, ENiGMA can run JavaScript (Node.js) based doors - just
    write one. Synchronet (though it handles it quite differently) can do
    the same AFAIK. At some point I plan on writing some door stuff -- and will probably create a small JS based door kit. node-blessed would be a good start here.

    NodeJS based doors is an interesting idea. :D

    |10Smooth|07<|11ACiD|08.|11b7|07>

    --- Mystic BBS v1.12 A31 (Windows)
    * Origin: .{* iNK!2 // bbs.inktwo.com \\ agoranet *}. (46:1/183)
  • From NuSkooler@46:1/173 to Smooth on Fri May 12 21:47:27 2017


    On Wednesday, May 10th Smooth muttered...
    the web or native mobile apps. There would be no need for polling if everything was synched up to a specific endpoint. BBSes would just have

    Right, theses days one can just use event driven/push. My plans involve decentralized though, so central endpoints or MongoDB wouldn't really cut it for that.. though the payloads should be generic enough to fit into other systems. JSON makes that easy.





    --- ENiGMA 1/2 v0.0.5-alpha (linux; x64; 6.9.5)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (46:1/173)
  • From Nightfox to NuSkooler on Fri Jun 2 14:21:18 2017
    Re: RE: New BBS Tech
    By: NuSkooler to Smooth on Tue May 09 2017 10:09 pm

    A JSON dropfile would be slick too -- and I've love to see people stop doing socket fd sharing (e.g. door32.sys) as it too much relies on the *door* doing socket I/O which IMO it would be abstracted from.

    Back in the day, FOSSIL drivers were made so that doors could be written to a standard interface to communicate with COM ports so they could be abstracted away from the technical details of each COM port implementation.. Seems funny that now we would want a new abstraction..

    Nightfox
  • From Smooth@46:1/183 to Nightfox on Sun Jun 4 11:26:01 2017
    On 06/02/17, Nightfox inked down this thought...
    A JSON dropfile would be slick too -- and I've love to see people sto doing socket fd sharing (e.g. door32.sys) as it too much relies on th *door* doing socket I/O which IMO it would be abstracted from.
    Back in the day, FOSSIL drivers were made so that doors could be written

    It's the sign of the times. JSON has more to do with data vs communication. It'll make it easier to share telnet data with web or otherwise. It'll make
    it more universal. As far as FOSSIL drivers. I find that they're just there to support older technology that don't have proficient COM support. That too will change as newer doors and telnet utility software are geared for 2017+
    and not 1990s. We can't stop progression. Otherwise the only systems that we'll be able to support our BBSes going forward will be retro ones.

    |10Smooth|07<|11ACiD|08.|11b7|07>

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: .{* iNK!2 // bbs.inktwo.com \\ agoranet *}. (46:1/183)
  • From ispyhumanfly@46:1/140 to Nightfox on Thu Mar 15 14:32:28 2018
    $ Nightfox was quoted saying . . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    A JSON dropfile would be slick too -- and I've love to see people stop doing socket fd sharing (e.g. door32.sys) as it too much relies on the *door* doing socket I/O which IMO it would be abstracted from.

    Back in the day, FOSSIL drivers were made so that doors could be written
    to a standard interface to communicate with COM ports so they could be abstracted away from the technical details of each COM port
    implementation.. Seems funny that now we would want a new abstraction..
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    I mean, it makes sense honestly. We've developed static data storage concepts and unified them across industries since the advent of the FOSSIL driver, drop files, all of that...

    I'm thinking that with BBS softwares adopting some of these more common strategies makes the barrier for entry smaller for would-be sysops perhaps
    more familiar with modern archtectures.

    --- Enthral BBS 0.700.2 (4.9.79-1-ARCH armv7l GNU/Linux)
    * Origin: haunting The chapel >>--> htc.zapto.org <--<< (46:1/140)