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)

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)

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)

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)

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

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)

$ 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)