cblgh/cerca

lean forum software

cerca's Issues

Localization on error strings

some error strings are localized, many are not, e.g. the embedded renderErr function in the Thread route. I assume the long term goal would be to localize these strings as well? Is there an example of the ideal pattern for localizing errors? I'd be happy to create a PR that at least sets up localization for all the unlocalized strings

Lowercase usernames

Right now Alex and alex are separate usernames. I think that the most clear approach is to force all names to lowercase. What do you think?

Refreshing after submission causes a repost.

After submitting a reply to a thread, refreshing the page in the browser will cause the reply to be submitted again.

Feature Request: Support for external/proxy authentication

Hello! I'm a merveillesian looking to use cerca for a makerspace organization. I installed phpBB and was almost immediately disturbed by the clunkiness and complexity of the admin interface. I think FluxBB is closest to what I want, but it's definitely not a workable solution anymore. I would rather err on the side of too simple, thus cerca!

I'm trying to keep all the IT services behind SSO so folks don't have to keep track of multiple logins. For example right now, I have Dokuwiki and Nextcloud authenticating against Keycloak.

I wouldn't propose adding OIDC or SAML support, that's way beyond the complexity of this project. BUT, there are ways to handle the authentication using a proxy in front of cerca:

• Apache Module
• OAuth2 Proxy

My understanding is that the proxy adds some HTTP headers specifying whether the user is authenticated and if so, some identification info. I don't know all the intricacies, but it seems cerca would "just" need to catch the headers and correlate with a user account (creating a new one if necessary).

Would this be a reasonable feature? It could actually be useful for the merveilles community, allowing a proxy to check membership on the Masto instance instead of manually confirming accounts, etc.

customize templates

one thing that's been raised recently as the other alex works on cerca are the templates of html/ and how necessarily entwined they become with the structure of the server package's code

perhaps we could explore an alternative where we have a folder /templates which is a directory of other templates, see bottom of post for a quick first sketch. the drawback is all of the duplication, so perhaps instead of duplicating literally every template file for each customized version, a patching approach could be applied: let's say there is a set of base templates (e.g. cerca as it is today) and if a custom template folder is passed (e.g. in config) then each filename that is found in there fully replaces the template of the same name among the base templates.

the thing to keep in mind is that /server's exported structs need to support all the data needed for all templates, even if a template doesn't use it but i think that could be tackled in a pieacemeal fashion. if someone does create a really extensive fork and wants to include too many changes then perhaps that does not need to be mainlined into cerca

> tree templates/

├── fishbb
│   ├── about.html
│   ├── about-template.html
│   ├── assets
│   │   ├── favicon.png
│   │   ├── merveilles.png
│   │   ├── merveilles.svg
│   │   └── theme.css
│   ├── change-password.html
│   ├── change-password-success.html
│   ├── footer.html
│   ├── generic-message.html
│   ├── head.html
│   ├── html.go
│   ├── index.html
│   ├── login-component.html
│   ├── login.html
│   ├── new-thread.html
│   ├── password-reset.html
│   ├── register.html
│   ├── register-success.html
│   └── thread.html
└── original
    ├── about.html
    ├── about-template.html
    ├── assets
    │   ├── favicon.png
    │   ├── merveilles.png
    │   ├── merveilles.svg
    │   └── theme.css
    ├── change-password.html
    ├── change-password-success.html
    ├── footer.html
    ├── generic-message.html
    ├── head.html
    ├── html.go
    ├── index.html
    ├── login-component.html
    ├── login.html
    ├── new-thread.html
    ├── password-reset.html
    ├── register.html
    ├── register-success.html
    └── thread.html

4 directories, 40 files

have it so that a post is automatically marked as read if you leave it

This way if you make a post and go back to the home via the logo, it doesn't look like something else has been posted.

Messages are resent when refreshing a page after sending

When I refresh the page after submitting a post on an existing thread, it submits the same post request again.

I figure if we are using a static (i.e. non-JS driven) forum, refreshes should be the norm of seeing if something new happened, so ensuring this doesn't happen seems like a good idea.

I'll dig around and see if I can put my finger on what could be done, but I am not anywhere near Go, so somebody else could probably spot it before I even get my shoes on

Steps to reproduce the bug

• Go to the test thread.
• Enter in some text in the textarea.
• Click "Post".
• Once the page loads, you should see the new post.
• Refresh the page. You should see a duplicate of the original post.

"Jump to Bottom" Link is Missing

Hello o/

There is normally a link in the header when viewing a thread that lets you jump down to the bottom of the thread, but it has gone missing sometime within the past month or so. The link element seems to still be there, but the text between the tag is not.

See image below for illustration:

The password reset tool linked from the reset page doesn't exist

I managed to fail to copy my newly-generated password into Bitwarden before copying my new keypair - oops, lost clipboard state! So I needed to reset my password again, this time not using the logged-in flow.

The logged-out flow appears to be broken: the linked https://github.com/cblgh/cerca/releases/tag/pwtool-v1 is a broken link, and I can't find a pwtool grepping around this repo anywhere to build it locally.

Go 1.22 Routing

Go 1.22 has some nice new enhancements to http routers https://tip.golang.org/blog/routing-enhancements

How would you feel about including these in the codebase? It would up the required go version to 1.22, which I know you had some reservations about

Add --base option to css compiler

With a --base option (or similar naming) the following invocation:

go run compiler.go --css ./../../html/assets/css --html ./../../html --out ./../../html/assets/themes

could potentially turn into:

go run compiler.go --base ./../../html --css assets/css --out assets/themes

(inspired by skimming thru @Thomasorus's recent twitch stream :>

Timestamps needs a bit of margin-left

Feedback on the CSS architecture for Cerca

Right now the forum has all its CSS inside the head and inline, which makes it extremely tricky and hard to maintain. We should think about a new way of organizing the CSS for the project.

This is not a post about design, only architecture.

Constraints

We have several constraints for this project, and we need to take them into account in the development. Among them:

• Support for pre-HTML5 browsers (notably Netsurf)
• A lot of our users deactivate JavaScript, which means we can't 100% rely on JS for some CSS transformations
• Our current default theme is not very accessible and should be made more easier to scan and read
• Still, the current theme or an evolution of it with the same design choices should still be available
• More broadly we should support several themes, including the current one, as an option
• Some users expressed the envy of customizing their themes

Technical ideas

Older browsers

Outside of layout (mostly flex and grid) and a few things that are not working (summary/details, svg), old browsers like netsurf should be OK. If we plan a fallback for all those issues, users should be able to get a very close experience.

To avoid losing making specific changes:

• Dev first for the legacy browser, then use @supports to unset the legacy values and add the new ones.
• Layouts should be utility classes with the fallbacks built in. This way we avoid rewriting them and support.
• Inlined SVGs can be replaced by background images with PNGs.

Themes

The trickiest part for themes is the support of old browsers. If we used custom properties present in modern browsers, we could have a single build and just changing the variables values would allow live changes for things like colors, spacings, fonts, etc. It would also be way easier on the backend, as we would only need one stylesheet with a few mediaqueries.

But to activate those mediaqueries you would need JavaScript. And using custom properties make our users with legacy browsers unable to see them.

The only solution then, is to build them using SCSS variables, and compile several themes in different files, and then let the user change its theme through a form and save it in his profile.

By making the code available and standardizing a config file with all variables in, we could also allow people to edit their own themes more easily and propose them to the community.

Imprortant! Users will not be able to change HTML, only CSS (think CSS Zen Garden).

No JavaScript required

At the moment we should not focus on things that require JS. But in the future we could do a few things that enhance the experience but are not required:

• Allow a change of fonts independently of the theme chosen
• Preview themes in the current page before choosing
• Insert new posts in a thread without reloading the page
• Delete a post without reloading the page
• Edit a post without reloading the page
• Etc...

I insist: progressive enhancement only. The forum MUST work without JavaScript.

Methodology

Since most things are very lightly styled, I propose we work mostly in utility classes:

• Create a list of design tokens for the themes
• Generate classes using those design tokens (margins, paddings, widths, font-sizes, colors, background colors)
• Design the forum with them
• Craft by hand a few utility classes for layout

This way it should be easy to support and easy to theme.

Feedback

Any ideas? Please be aware this is not a discussion about design, but about the technical side.

Pinned threads

I was thinking about adding 'user profiles' but I think a better solution would be to use the new admin functionality to allow admins to pin threads. then one could create an 'introductions' thread. this is how I recall old school BBs operating, there wasnt really much you could set on your user profile

More granular relative time

Right now, timestamps are "today" or a date.

How would you feel about using relative timestamps (x [block]s ago) that on mouseover provide the exact RFC3339 timestamp? Something like this https://git.alexwennerberg.com/flounder/file/utils.go.html#l104

"Topics" discussion

Just wanted to update you on some work, I'm working on a PR to add topics. Here's a screenshot:

I think this is aligned with what you're looking for? Next step is for me to add headers by topic.

I'm also thinking that topics should lead for a greater desire for "pinned threads" (#51 )

I'm wondering if the RSS feed should be global, or by topic. Maybe both?

Invite tree system

My fork uses a very rudimentary invite system https://github.com/alexwennerberg/cerca

It would be interesting to have, alongside the site-based verification, a toggle-able 'invite tree' system, where people receive a small number of invites (like 5) and can invite other people. https://lobste.rs/ does something similar

to prevent spam (a malicious account getting infinite invites), we could do something like a 24 hour waiting period before invites work

Verification link's host is not in the allowlist

Low priority issue but I'm having trouble signing up for the forum since my site wiki.plungepool.dev (newly added to the webring within the last week or so) apparently is not in the allowlist. Not sure if this requires a manual update or redeploy to generate a new allowlist. No rush, thanks for your help!

err404 and other error pages return 200 status code

It appears that the error pages, by and large, return 200 status codes rather than non-200 error status codes

I'm writing some new code that will set non-200 status codes on errors, but should I also update existing code likewise?

Proposal: add datetime attribute to threads

Currently, threads are ordered by their id. It would help to order the index by the datetime of the last post of a thread.

This is not something to encourage social media-like behaviors, but the simplest/lightest way to have a sneak peak of what one may have missed since their last visit. To limit the noise, I don’t think that we should show a snippet of the last post, but a simple indicator like last post: 20XX-XX-XX would be enough.

Currently, we only save the date to posts, maybe a full timestamp following RFC339 on the UTC timezone could help with collision too.

The header just vanished

Can't go back to the threads page.

Proposal: Allow ctrl + enter to send the post

I do it a ton unconsciously because it exists in mastodon. Might be nice but Idk how complex it might be.

"Admin" link missing on some pages

on e.g. /about, there is no "admin" link in the header, I believe because IsAdmin is not populated.

With IsAdmin and Pending booleans, I wonder if storing a larger 'logged in user metadata' struct rather than getting each field individually may be valuable, and reduce code duplication

Webring domain not in allowlist

I'm seeing the following error when trying to register for the forum:

Verification link's host (plastic-idolatry.com) is not in the allowlist

This domain was added to the webring recently. Is it possible the server needs to be restarted or something? Does the service pick up new domains dynamically?

Code structure and development enhancements

I've created #26 which makes some logging changes and I've alluded to some broader code structure changes I can spot as worth doing, I thought I'd list them out here just so it all makes sense:

• Linting: My first step was to integrate golangci-lint as part of the CI process to test against some of the code smells that are easy to make in Go otherwise
• Logging (#26): As part of the linting, there were some changes around the use of fmt that needed to be made, and starting with a dedicated logger want a good starting point for that
• Migrations: The current code has a structure for migrations, I was planning on rounding that out and making it functional
• Structural: This will deserve its own issue to discuss, but there are some folder/code structure changes that can be made which will make it much easier to navigate and use the codebase
• Reliability/robustness: The current code can use some edge case and reliability love. This isn't a bad thing, I think it just takes a bit of time to get this stuff running that is often better spent on features, but I can probably add value in.
• Testing: Automated tests, particularly fuzzing tests will be good to add in to ensure things are working as expected.
• API: The structural changes and testing should make adding an API layer a pretty simple endeavour

Usernames being styled in the same way as the post content could be ambiguous

So the image is of a single post with the content:

blep

**ciel**

ok... spacing might not be the same

I don't believe our members will be malicious with this, but current styling makes the usernames and the content ambiguous.
Of course, spacing isn't the exact same of when a user actually posts. But it might be worth it to make it visually obvious to prevent (even accidental) confusion.

Open singups discussion

Sorry for all the issues today, I've been doing a lot of work on cerca haha

I've been working on an optional boolean to allow open singups. This involve creating a concept of shadowbanned / "hidden" users. Posts by these users are visible only to themselves and admins

admins can then either unhide a user's account, or ban them if they are spammers. This allows users to participate immediately without something like email confirmation, while also locking spammers out of making posts (while giving them no visible feedback that their posts are invisible)

I would imagine this isn't necessarily what cerca is originally designed for, but I don't think it deviates too far -- and I think it makes it easier for small communities where an admin can simply ban anyone who isn't in the targeted community, while also making it so it's easier for people to sign up

WIP implementation on aw-fork2

#59 is intended to lay the groundwork for this, simply so people can't extremely trivially ddos the server and make the site unusable for admins

"Prod readiness" -> anti spam and input validation

There's a number of features I'm looking to make cerca more "production ready", ie, resilient to a few classes of attacks:

1. Size limit on every form input
2. Rate limit on every POST route

This may be a somewhat substantial PR, so I wanted to touch base before writing thi

Edit support for posts

I just made a post on the Merveilles forum and, after hitting submit, realized that the formatting was off for my ordered list. The lack of edit functionality makes it so I can't go back and correct it which made me think of this.

Is there any interest in adding this functionality?

Cerca CSS compiler project

Hey folks!

Following @cblgh wish and @sansfontieres idea, let's talk about our own custom CSS compiler to write in GO!

A CSS compiler? Isn't that a big... BIG?!

Yeah a little bit, so let's reduce the scope and evacuate a few things first. The goal isn't to reproduce what the NPM ecosystem proposes, aka compiling from superset of CSS (SCSS, SASS, etc) and compatibility features like autoprefixing, fallbacks, stuff like that. We want solely a small generator, importer and cleaner.

Generator

Like I explained in #17, my goal is to have design tokens. Designs tokens are single piece of design, like a color, a size, a font-size, a border, an underline... Design tokens can then be combined into classes.

Let's say for example we have a scale of sizes. Those sizes are incremented by 0.25 and we start at 0.75. I'll use the CSS notation but that could be JSON or anything else.

:root {
--1: 0.75;
--2: 1;
--3: 1.25;
}

We can use this scale and CSS logical properties to create utility classes:

.padding-1 {
    padding: 0.75rem;
}
.padding-2 {
    padding: 1rem;
}
.padding-3 {
    padding: 1.25rem;
}

.font-size-1 {
    font-size: 0.75rem;
}
.font-size-2 {
    font-size: 1rem;
}
.font-size-3 {
    font-size: 1.25rem;
}

And many more!

Why use design tokens and generate those classes? For two reasons:

1. Design tokens create an harmony of sizes and colors based on scales make the design more cohesive, pleasant, and avoid writing hard random values.
2. Utility classes based on design tokens allow us to style single elements without create a dedicated class like .box-card

With these, we can do a first pass on all templates, adding padding, margins, font-sizes, colors, font-families, etc... It's also way more easy to understand for people not too familiar with CSS. Want bigger font-sizes? Change the scale! Want another color for your links? Just change it!

So we generate those classes and put them into a file. But that doesn't mean it will work for everything, far from it!

Importer

We still have some classes to write by hand. Some of them can use the design tokens. For example the flow classes, that are used to detect if two elements are adjacent and add margin between them, are often a good way of having a good vertical flow in a page and cannot be generated solely by design tokens.

.flow-1 *+* {
    margin-top: 0.75rem;
}
.flow-2 *+* {
    margin-top: 1rem;
}
.flow-3 *+* {
    margin-top: 1.25rem;
}

If you did not know, using + avoid writing :first-child or :last-child to remove borders applied to all elements.

To organize those classes into logical elements, we could use partials of CSS. There's a convention that we could reuse from SCSS, which is to prefix all imported files with _. For example: _flow.css.

Writing in the index.css a list of files we want to import already works in CSS... by requesting all files one after each other. Ideally, we want everything into a single file that we can compress using gzip or brotli (the server can do it).

So the goal would be to create a list from the index file and find in subfolders each _*.css files and concatenate them. In the end we would have everything inside a second file, both our generated classes and our manually crafted classes.

And that's an issue: the file is going to be way too large.

Cleaner

Let's say we want to generate a lot of utility classes with our design tokens. We want padding, padding-left, padding-top, padding-right, padding-bottom, padding. The same for margin. Then we wan gap and grid-gap. We want background-color and color for our colors. We're gonna have a ton of classes we could be using, but might not use in the end.

That's why we need to clean our file. The best way to do it would be:

1. Scan classes declarations in our template files
2. Using this dictionary of names, remove all the unused ones inside our compiled css file.

In the end, only what we end up using would be there, while still keeping the possibility to use new utility classes. Note that we could clean the declarations before we import all files, but doing it an the end also allows us to remove unused manually crafted classes, like the .flow classes.

Conclusion

I don't know GO at all so I can't really say exactly how to proceed since I don't know what the language is capable of. If you have suggestions about how we should declare design tokens, if importing files is easy or not, if the cleaning process is doable or not, please share!

I'll leave you with a few links:

• Gorko, a token class generator written in SASS: https://github.com/hankchizljaw/gorko#getting-started
• PurgeCSS, an unused CSS remover: https://purgecss.com/
• Cube CSS, the methodology that consist of styling with your own utilities, them doing specific classes: cube.fyi/