Exciting stuff!
Mon Jun 04 2018 11:00:47 EDT from IGnatius T Foobar @ UncensoredIt's a pretty obvious change when you think about how web software is done now. It still bugs me to have to "start over" in a sense, but when the WebCit project was started in 1996 I really didn't know what I was doing. It was a couple of CGI scripts clumsily lashed to a server process that talked to Citadel, and presenting a UI using any weird hack I could manage. The design pattern was wrong, the code was badly laid out, and the built-in web server was bolted on four years later, adding more spaghetti to the code. The templating language seemed like a good idea at the time, and the implementation was pretty powerful, but it made code maintenance almost impossible.
webcit-ng is written very cleanly, with good separation between layers, and avoiding some of the design mistakes made in other parts of the system. For example, we pass all of the state of both the HTTP transaction and the Citadel session up and down the stack instead of constantly querying for thread-specific data. And to be honest, there are places where big chunks of code are being brought over from legacy webcit to webcit-ng, but they're being cleaned up and fitted into the new program instead of trying to fix what was in the old program.
It's a great little project and I'm really happy with what we've built so far. But that's part of what's making it take so long. And of course it doesn't have a UI yet. :)
Looking forward to it IG, but I share your practicality. Still wish I had time to come up to speed on things and help in this effort.
P.S. I did not get back to the folks that were using the now deprecated citadel room sharing code. I figure that will be locked in time (i.e. until they re-flash something and decide to test some update at a future date). Hoping I get the time to explain all the new and exiting changes you folks are planning for the future to share with them when I am able to spend more time on implementation bits.
I am also happy to hear that you have an ear for the passion for taking in the best bits out there. Keep up the good fight and know that your efforts (and all the Citadel coders) efforts are used and appreciated. You are all unsung heroes as far as I am concerned.
You could probably do it today using RSS, but I haven't tried it.
True. I had not thought of exploring the room features. I had used the mailing lists in the past (great feature that goes underused I think). The RSS feed is one I use every day though. Another great feature. Been doing a bit of Gopher lately for movie listings without any ads, weather reports, browsing the news. Feels nice to be able to get the content without all the rest of the crap - same way the RSS feed does for me. It also has the feel of using the text client (sort of).
I have been using the movim social networking/xmpp system, and truly love it - just as i love Citadel. So i just created a chatroom for anybody that might be interested on Uncensored.
https://nl.movim.eu/?login/pCWx8ntu
I thought maybe someone would be interested in the architecture of movim. So here is a blog post by the lead dev. It's always nice to hear the whys and hows of any project you like.
https://nl.movim.eu/?blog/edhelas%40movim.eu/how-s-made-movim-part-i-the-architecture-CCA7If
Yes i can understand where you are coming from, but what if the herd just migrate to another, closed garden of a system, like Face**k?
Actually movim is just a plain old XMPP client, and while being around the XMPP people, i see many new systems and much activity within the XMPP community. I can see no reason to not
stay with XMPP as there is tons of exciting things happening still. And this was one of the things i think citadel was a little weak on in the web client, the XMPP feature really is great, but the interface could be much better.
I feel bad to say anything bad about citadel, because it is such a wonderful system, and i am not offering any solutions or help as some here do.
I really don't think you should be waiting for any new fad to come along, social networking systems are everywhere, even wordpress has a seemingly good social networking plugin for it's system i see. None of the systems the herd will migrate too is likely to use an open protocol are they? I'm not sure, but here at citadel you already have a system made with open protocols, especially email, which is everywhere and - correct me if i am wron - not likely to go away soon(?) and also XMPP which for all the things i heard of it's demise, i do not feel this is the case either - correct me if i'm wrong (?) but already having the userbase, albeit not the billions of the walled gardens now, and still many people building very large commercial systems with XMPP, aswell as the general populace - 'and' as this guy that built movim- among many - shows - a simple xmpp client with a nice interface is about all you need for a nice social network. I think Citadel already has a headstart in this department, it 'can' be used as a social network, even though that was or is not the focus, i'm sure there is a place in this world for a social network system which is built on open standards - which uses email which everyone on the planet seems to have, and which would be totally decentralised.
You probably know me by now, for a bit of , maybe nieve enthusiasm, but has any of that any merit in your opinion?
Here are two XMPP projects - out of many - one a system for the 'man in the street', and another for the enterprise.
https://salut-a-toi.org/overview.html
I like SAT, it is very new but has many features and lots of possibilities, and a few nice frontends. Also has gateways to connect to any protocols, and connects to email right now.
Worth having a look at the features and frontends pages.
This project works with enterprise communications companies, including Mozilla, aswell as individual developers.
As an old BBS user and co-sysop, I really appreciate the existence of such an old system, as it's still under development.
I'm a web developer who loves to use React and Redux. I would like to write a web app for citadel, if there would be an open and complete API, which I could use to realize such a project. Is there a documentation and repository, where I could contribute such a thing?
In my mind, I like to realize a web app with a modern UI and another one, which simulates a terminal inside the browser.
Subject: Re: Contribution to realize "ReactCit"?
It's documented here: http://www.citadel.org/doku.php?id=documentation:applicationprotocol
We'd absolutely love to have additional user interfaces to the Citadel system available. The more the better.
That's great! Thank you for the link! :)
Subject: Re: Contribution to realize "ReactCit"?
Sat Aug 25 2018 17:06:10 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Contribution to realize "ReactCit"?You're welcome! This is the exact use we intended for the protocol -- different developers working on different use cases with the Citadel server as a common underpinning for all of them.
I love that!
Hope I'll find some time. I've realized, first, I have to write an HTTP to TCP bridge to get an HTTP based API for my client based web application. Let's see ;) ...
Subject: Re: Contribution to realize "ReactCit"?
Hope I'll find some time. I've realized, first, I have to write an
HTTP to TCP bridge to get an HTTP based API for my client based web
application. Let's see ;) ...
Right. In any web based Citadel application you'll have to find a way to make the protocol *appear* stateless while actually maintaining server connections.
That will of course require some sort of middle layer.
In the current version of WebCit we handle this by rendering the entire UI server-side, and using cookies to connect HTTP requests to the correct session, and that session has a pinned-up connection to Citadel.
In the version being developed (webcit-ng, which you can find in the git repo) we're exposing a REST/DAV interface to Citadel, and rendering the UI on the client side. When a client performs an HTTP transaction it hunts for a session that is connected as the correct user (or as not-logged-in if appropriate) and binds to it for the duration of that transaction.
The obvious question is: why didn't we build the bottom layer as REST/DAV from the beginning? The answer is: it was 1994; who knew?
Mon Sep 03 2018 14:26:54 EDT from IGnatius T Foobar @ Uncensored Subject: Re: Contribution to realize "ReactCit"?Hope I'll find some time. I've realized, first, I have to write an
HTTP to TCP bridge to get an HTTP based API for my client based web
application. Let's see ;) ...
Right. In any web based Citadel application you'll have to find a way to make the protocol *appear* stateless while actually maintaining server connections.
That will of course require some sort of middle layer.
In the current version of WebCit we handle this by rendering the entire UI server-side, and using cookies to connect HTTP requests to the correct session, and that session has a pinned-up connection to Citadel.
In the version being developed (webcit-ng, which you can find in the git repo) we're exposing a REST/DAV interface to Citadel, and rendering the UI on the client side. When a client performs an HTTP transaction it hunts for a session that is connected as the correct user (or as not-logged-in if appropriate) and binds to it for the duration of that transaction.
The obvious question is: why didn't we build the bottom layer as REST/DAV from the beginning? The answer is: it was 1994; who knew?
Thank you for the hint concerning webcit-ng.
I'll take a look at it. Maybe inkI build my version on top of the ng.
It may be an idea to build the REST API as a separate module to allow every client based web application to use it...
Subject: Re: Contribution to realize "ReactCit"?
I'll take a look at it. Maybe inkI build my version on top of the ng.
It may be an idea to build the REST API as a separate module to allow every client based web application to use it...
That's one use case I had in mind. We're being careful to keep the REST API cleanly segregated from the UI code so that other web clients can be swapped in.
The only issue is that the API is far from complete at this time. You can log in, list rooms, and read messages. I'm implementing API calls when I get to the point in the client application where I need them.
I keep feeling the need to switch between "pause after each message" and not
with ".ec" (enter configuration). It would be so much simpler to have an
option to "read continuously" after every message like many of the old BBS's
had.