Camen Design Forum

Let's rewrite NoNonsense

append delete Kroc

:: Why?

OK, here goes. The last two years have been rough. Raising a baby is tough. Broken sleep is tough. Depression is tough. My website has languished and I need to get back to writing because life has changed so much.

I want to create a new NoNonsense that combines Blog, Forum and possibly Wiki. I will run my website off of this new platform whilst also making it available to all to use themselves.

The goals of the Camen Design website back in 2008 have been completed. I don't need to create an HTML5 masterpiece, I just need a site that's flexible and that I can update anywhere.

I need your input.

:: What Do I Require?

Here's the minimum that I require for my own needs:

* Blog with ability to handle drafts & file uploads
* Compatibility with existing Camen Design content (ReMarkable)

:: What Do You Require?

Please let me know what you would want from a new NoNonsense platform.

These are some things that stand out to me as requiring deep integration from the start:

* Plugin interface
* "Teapot" design methodology - all functionality full scalability from 320 x 240 to 4K
* Full online administration (create/rename/delete folders, threads, posts &c.)
* Flood/ban control and better resilience against abuse

:: @Kroc added on 03 Apr ’15 · 14:05

Also needed from the off:
* E-mail subscriptions
* YouTube / Image markup parsing

Reply RSS

Replies

append delete #1. tagg_

Convert a blog post and it comments to a forum post and vice versa.

:: @tagg_ added on 06 Apr ’15 · 06:41

Dealing with password resets.

append delete #2. Kroc

Yes for password resets of some kind. The blog will most likely be stored as its own forum but with a different HTML interface to it. That way blog posts and forums threads would be freely exchangeable (RSS feeds)

append delete #3. José Pedro Arvela

I think the main point with passwords is that they are a single point of failure. If a password gets discovered, then it's all over. If it gets lost, it's all over too.

A choice would be adding anything to these passwords that could act like a backup (an email, for example). But that goes against the ideas of simplicity and being hurdle free.

Another option would be to, instead of adding a reset password, to add a disable account, which can only be used with the password.

That way, if an account gets exploited, the creator himself can, at any time, close the account and prevent any damages.

This helps avoid impersonation, but it doesn't prevent it altogether. Nor does it deal with the possibility of losing a password. Nonetheless, it ensures at least that each person who has an account is in control of it.

append delete #4. Martijn

That way, if an account gets exploited, the creator himself can, at any time, close the account and prevent any damages.

This sounds a lot like Wikipedia’s “user committed identity” system: you can set-up an SHA hash for your profile to be able to prove you are the legitimate owner of the account in case of a compromised account: http://en.wikipedia.org/wiki/Template:User_committed_identity

In all fairness though, if you are going to be using this as your personal blog you probably want a slightly higher level of security than can be offered by NNF’s current simplicity. Some more up-to-date security practices (salted scrypt, or at least bcrypt, hashes for passwords) would be a start.

Or maybe go password less? Several people have been trying this in the last couple of months. One-time-passwords sent to an app or email address, or just an instant login link in an email message. This would be pretty simplistic for users, but is non-trivial to implement.

append delete #5. Kroc

I don't think I can solve the world's password problems -- not without the browser vendors support :P

@Martijn

if you are going to be using this as your personal blog you probably want a slightly higher level of security than can be offered by NNF’s current simplicity

In my mind the site owner always has access to the FTP/Host, so they've one more level of control than a regular user and wouldn't get pwnd in one hit. Security methods will be improved in the new system.

At the moment I am at the conceptual planning stage. What you may not know is that when it came to creating NNF, I experimented with several different radical possibilities.

I looked at using RSS+XSLT so that no PHP would be needed, but in-browser XSLT is broken and dying (in an ideal world we wouldn't be writing code that we have to maintain, everything should be declarative).

I also considered having all posting and replying being done through e-mail rather than web-forms. It would be a good way to do things, but processing text from e-mails is a bag of hurt given how badly mail clients munge the source and I didn't want to delve into that.

I went with HTTP_AUTH solely to avoid using a browser session that is less secure, tends to expire (more code and design needed) and was overkill for what I wanted. For a new, complete system I will use a session but I want to be very cautious about how much user data I store, how I store it and so-forth.

NNF's style has been that the user name & password hashes are the only things stored so these are useless if acquired. But if I move to storing e-mail addresses and the like I'm much more worried about the implications of storing, managing and protecting this information.

Because vendors have given up on RSS (damn them and their ignorance), I can see the need to have mail subscriptions, but there is much to consider and I want to handle it well.

Or maybe go password less? Several people have been trying this in the last couple of months. One-time-passwords sent to an app or email address, or just an instant login link in an email message. This would be pretty simplistic for users, but is non-trivial to implement.

I've never heard of this concept before, that is very interesting. It definitely improves account safety, but adds many hurdles to the end-user. Much to think about here.

append delete #6. TCB

::Passwords and Security

maybe go password less?

To me, the password-less concept seems very much like simply making the "forgot your password" option the first or only option. It's like doing a password reset every time you log in. Not sure I like it.

Something I'd like to see is backward compatibility. For my purposes, NNF works fine as it is. So as you add layers of security for the blogging platform or for hardening forum access, I wouldn't want them to supplant the current system. Rather there should be levels of security that can be applied as appropriate.

One of the common use cases for NNF has been as a private forum. One thing I don't understand in that scenario is the appropriate method for meshing together login access to the restricted area with NNF's username and password. So when someone logs in to the restricted user area, their identity is seeded into NNF. If there is a good way of doing this, it may show the way forward as far as better security for a more robust No Nonsense platform.

::Spam

The CMS software I use has an effective approach to dealing with both human and robot spammers detailed here: http://www.couchcms.com/forum/viewtopic.php?f=8&t=7047

It uses a simple question like "What color is a blue apple?" to confound spambots and checks the database at http://www.stopforumspam.com/ to weed out human spammers. NNF ingeniously uses a fake email input as a sticky trap for bots. If an actual email input becomes part of the security system, you'll need something to replace it.

I've gotta slip in a plug for CouchCMS. It's simple but powerful, fully customizable, open source, and actively developed by a friendly, helpful group of users and developers. You may find some useful ideas for your own project there.

::Email subscriptions

Mailchimp and probably others provide free and easy to use RSS-to-Email capability. Since NNF is RSS-based, you can check that one off unless you want to write your own email management system. (yikes!) NNF as it stands could easily integrate email subscriptions. I post something to a blog and the next morning at 5am it is sent out to my list of subscribers as a fully styled html email. RSS has just moved into the background as a syndication service, with developers using it to push content rather than users actively pulling it. I'm of the opinion that it was passive users that gave up on RSS (damn them and their ignorance). But it's still there.

::YouTube/Image Parsing

I think this list could be much larger. It's appropriate to leave all that cruft out of NNF, but when it comes to a blogging platform, who knows what you may want to share, show, or include? You don't want the platform to constrain you. I don't know, maybe tables, other video platforms like Vimeo, social crap from facebook, twitter, instagram, and so on. How about a script to open an overlay, or do animations? HTML5 video, form input, even flash.

My point is that when it comes to expressing yourself, there are endless possibilities and your platform should be open to them. You may start with some built in markup for common uses, but the blogging platform should be open to what the user wants to include. A plugin interface could be useful for extending the platform's capabilities. Couch also uses a system of shortcodes that allow a developer to create his/her own custom markup for specific purposes.

It's a lot to think about. All the best. Good talking with you again.

append delete #7. Kroc

@TCB

It's like doing a password reset every time you log in. Not sure I like it.

I wonder if we could create an "identity slug". You sign in via e-mail / form and you are given a unique hash URL; e.g. `?id=2fd4e1c67a2d28fced849ee1bb76e7391b93eb12`. You can bookmark that URL to be able to log in at any time. The same URL could be used to disable the account, should someone else get hold of it, and a new access URL can be e-mailed out so that a hacker cannot permanently control or disable someone else's account.

Something I'd like to see is backward compatibility

I will, to what extent I can, provide backwards compatibility -- or rather sideways compatibility. The new system will store threads in a sub-folder without mixing them with the system files (NNF only did this to support non-htaccess servers in the simplest manner). A mod_rewrite rule could forward the requests to the sub-folder to keep previous permalinks.

The new system will begin with the existing hashing method and then do some additional hashing on top so that old user files can be imported without having to know the passwords.

One thing I don't understand in that scenario is the appropriate method for meshing together login access to the restricted area with NNF's username and password.

Unfortunately Apache / HTPasswd are awfully limited. We could get NNF to create the .htpasswd files, but then we have limited options for salting. Enabling/disabling HTPasswd on demand is also difficult. I'm looking into it.

Mailchimp and probably others provide free and easy to use RSS-to-Email capability.

I would never require users to have to register with another party. My software principle is "copy, paste, run". The product should function without any external configuration or setup. (e.g. SQL database server)

" I post something to a blog and the next morning at 5am ..."

Shared hosts don't provide access to CRON. We will have to send subscription e-mails out when a post is made. I worry about over-spamming a user with a busy thread, so I need to perfect a method of flood control, whilst still working without CRON.

A plugin interface could be useful for extending the platform's capabilities.

This is the intention. For blog/admin posts, full HTML will be allowed so people can embed what they want. The new system's markup will auto expand YouTube / picture URLs into embeds; nothing over complicated.

---

P.S. This post took three days to write. My son has been keeping us up at night for weeks now. Sooo worn out.

append delete #8. TCB

We will have to send subscription e-mails out when a post is made. I worry about over-spamming a user with a busy thread, so I need to perfect a method of flood control, whilst still working without CRON.

An alternative would be to provide some sort of control panel or interface where the site owner can manually choose when to send email. That way they're responsible for the schedule. They can do it once a day, once a week, or every 5 minutes depending on their needs. They could also choose which threads/feeds to send to which lists.

Automated email is a delicate issue. There are specific legal requirements involved in managing lists, server settings involved in avoiding spam filters and blacklists, and a whole lot of other trivial but absolutely necessary details involved. To my mind it really is something best left to an external service.

No matter how much parents love their children, they cherish the time when they're asleep. It's a tragedy when it gets interrupted. "A sleeping baby is a gift from God."

The best advice I know of for family sanity is a regular schedule. Regular mealtimes, regular naps, regular baths, story times, bedtimes, and bedtime rituals. Don't overlook the value of good naps. A well rested baby sleeps well at night. But advice is just talk. In the end you get what you get and you don't pitch a fit.

append delete #9. Jason Sackey

I'm interested in how you'll approach the wiki component (if this possibility is realised). I'd very much welcome a simpler alternative to the existing wiki systems I've looked into.

Smallest Federated Wiki is an example of a rather unusual type of wiki system that you might consider taking inspiration from. Unlike Wikipedia which tries to achieve an agreed consensus on one document for each topic, this encourages individuals to maintain their own separate wikis with separate pages, but still linked together, and content is forked and copied throughout a 'neighbourhood' of the sites.

http://fed.wiki.org/view/welcome-visitors

append delete #10. David Hund

(Not sure if off-topic)
Ever since I came across NNF I was impressed with its elegance.
Also: I immediately though something like this (but preferably even simpler and not completely PHP-based) would be great for blog-comments on static sites.

As you are probably aware there is a real momentum going for 'static' websites: simple sites generated through e.g. Jekyll (Ruby), Metalsmith (Node) or any other tech. and deployed through gh-pages, Surge or simply by uploading the files through FTP.

What these static sites are missing, obviously, is 'dynamic' stuff such as comments. So they use disquss etc. — ಠ_ಠ

I love the idea of (generating) a comment-thread as RSS with each comment being an item and have been thinking of something like NNF for this.

The biggest challenge, obviously, would be how to 'generate' POSTed comments from a 'static' site. We might need some dynamic middleware (PHP, Node, whatever). Maybe even e-mail (thinking out loud).

What are your thoughts?

append delete #11. wk

Hello,

I've been coming and going for about three years now. Even though I haven't used your script, I find it's simplicity very attractive. With that being said, keep it simple.

I feel like a combination of a blog with forums would be a great idea. A wiki? Not so much. Maybe for a blog, you could fetch data from a specific RSS file, or forum, and display it in a different directory?

A few things I would recommend would be creating a simple, yet effective, admin/moderation control panel. With this, track users IP's. Fetch all posts by each IP and give an option to delete posts, delete ALL posts and ban an IP from using the forums. There's a script called tablecatbbs that has a wonderful admin backend for it being an anonymous board. Similar to that of Tinyboard, which is an imageboard.

Lastly, I would include a "report" function, where users can report specific posts with a reasoning. This would display like posts in the admin/moderation control panel.

If the backend was there, I would most definitely switch over to this script.

append delete #12. Martijn

@wk: such a control panel will really only be possible if NNF switches from its current elegant RSS-storage to databases. The reason IPs aren’t stored for every post is that they would be stored in a place accessible to everyone on the internet. That’s not what you want.

This is all about user management, a tough nut to crack if you want to keep things simple

append delete #13. wk

@Martijn

Tablecatbbs (http://tablecat.ipyo.heliohost.org/perl/) doesn't use a database and is able to track IP's. The IP's are only available in the admin CP.

I'm just thinking it would be nice to have better control of the board, it's posts, etc.

append delete #14. Martijn

Then Tablecatbbs does not use RSS-storage 😉 All information used to render a thread on NNF is stored within the RSS file for that thread. No double data storage, all static. But the RSS is available to everyone.

NNF has some non-public data as well. The user data files (with the password hashes) is an example of that. But it would be hard to put IP addresses somewhere non-public and still keep them closely related to the actual post content.

Now that needs to be solved for the NNF rewrite…

append delete #15. tmyusuf

Reset your password

append delete #16. Joshua

So my first question is why do we need to integrate a blog and wiki? What does it bring to NNF that we need? For me I use a static website generator. I don't need a blog but a comment system and preferably a drop-in JavaScript.

Can we have atom feeds with paging and archive support? Which would give easy pages and make page size even smaller and more modular.

https://tools.ietf.org/html/rfc4287
https://tools.ietf.org/html/rfc5005

append delete #17. Kroc

@Joshua: It's more of a low-priority thing, though the reasoning is that integrating multiple different products for one site (blog, wiki & forum) is very painful and there are sites that use all three: http://smspower.org & http://sonicretro.org for example. Though to be honest, I would never want to match their features, a Camen Design wiki would have to be fundamentally different than existing wiki software.

Can we have atom feeds with paging and archive support?

Yes, that would be a bear-minimum requirement for any new NNF. (I'd also want it for multiple-attachment support)

append delete #18. festinia

> YouTube markup parsing

To me this is nonsense, those "social" things are unneeded and not welcomed in a no nonsense environment.

maybe image could be useful.

append delete #19. Octomoose

@festinia

Eh, not everyone wants to utilize this as no nonsense software. This and an image markup would be very nice.

Something that also would be nice is a "preview" feature. Which would help for laying out all the markdowns.

append delete #20. gustaba

I would like to see a markdown editor that allows you to preview your message, as well as image upload[1].

[1]: https://bbs.neet.tv/lounge/read/5#bottom

append delete #21. hank1

@gustaba

This would be very handy, being there are no edits.

append delete #22. Kroc

A rough outline of development is as follows:

* Learn up to date development tools (PHP 5.3/4/5/6, 7), PHPUnit, Composer

* Upgrade DOMTemplate, adding proper css->xpath translation

* Begin to outline an NNF kernel with 'everything is an extension' support; DOMTemplate will allow us to repeatedly mutate the HTML according to each extension's needs without stepping on each other's toes (and with easy to use CSS selectors)

append delete #23. hikse

hi,
I don't have any particular idea for the future of NNF, except maybe the use of SQlite as a simple database.
I just want to encourage you to continue the developpement.
Seriously, this forum is the best. No subscription pain, simple installation.
just, thank you.

append delete #24. Arabic

Best Quick and easy forum wish to continue to develop non-stop
It really is the best forum used.

append delete #25. john.griessen

" “We will have to send subscription e-mails out when a post is made. I worry about over-spamming a user with a busy thread, so I need to perfect a method of flood control, whilst still working without CRON.”

An alternative would be to provide some sort of control panel or interface where the site owner can manually choose when to send email. "

How about a plugin that is a relative timer per login. Not a calendar:hours:minutes:seconds clock, but a countdown timer that is set for each login. When a busy thread gets new messages, they all go out after a delay, not one at a time. If the delay was 7 minutes, the messages would trigger emails at 7 minutes for most short conversations, and when messages keep being generated rapid fire, the countdown keeps getting reset so no emails go out until it dies down.

Reply

(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Kroc, Impressed, Martijn