Guestbook providers?

[Daniele63]

Right now, the only guestbook providers I know of are SmartGB and Atabook, but they both have flaws:

- SmartGB has sponsored ads, which you need to pay to get rid of, but it has RSS support
- Atabook recently introduced a supporter tier, and it is not clear if they will add advertisements in the future, they also don't have RSS support or the ability to export messages.

I was wondering if you people of melonland know of any guestbook providers that is better, or options to self-host one without ads and full control, that would be even nicer. If you know any, please let me know, thanks!

I'm really terrible at PHP so making my own isn't really something I want to do, as a guestbook is something that should have at least some anti-spam and security measures put in place.

[Melooon]

There's a few threads related to self host options such as PHP Guestbooks and Perl Guestbooks - I've not tested any myself, but the impression I get is that they are functional but prob a bit jankey 

I've been a paid smartGB member since I first started my site and they have always been reliable, however Im getting close to the 5000 message limit; I did e-mail them to ask if they would lift the limit for me, but they have not responded yet If the time comes that I'm about to hit that limit, I'll prob code my own guestbook service and open it to ML members toooo.  Atabook is fine, but I dont think I'd switch to another 3rd party hosted GB. Plus I feel like there are more fun things to do with guestbooks if you are coding one from scratch!

[Dan Q]

If the time comes that I'm about to hit that limit, I'll prob code my own guestbook service and open it to ML members toooo.

Heh, this is literally something I've already been thinking about doing! - a free/donation-accepted guestbook system that tries to do similar things to atabook but with better integration options, for Melonlanders and perhaps a few other communities too. And all open-source so anybody can selfhost if they really want to, but available as-a-service for free anyway.

Unfortunately I'm a little bit "out" of the guestbook game and so I'm weak on what-features-people-actually-want out of their hosted guestbook service! What are people looking for?

[Melooon]

literally something I've already been thinking about doing!

Oh please do it, the reason I've not done it already is that its just low on my priorities compared to other projects here and I have too many ideas

Some initial brainstorming ideas and also must have features:

Must Haves:

• Ability to have messages hidden until approved (with optional pre-approval for ML members)
• Ability to reply to messages without it just being another message
• Basic spam filtering for junk and duplicates
• Rate limiting for non spam e.g. 1 message per IP per day
• Word/URL censoring (maybe regex)
• Ability to provide your own HTML template
• Ability to provide your own CSS
• Basic CSS and JS templates provided
• Backup export and import system
• embeddable + SSL
• RSS feed, plus e-mail alerts
• Custom emojis/32px gifs (like discord) - integration with PixelSea search

Extra Haves:

• Doodle messages, with a lil pixel art drawing tool.
• Audio messages (apparently only I like these?), also micro videos! (but really micro, not like the Tok, like old phone MMS messages)
• Novelty layout support, such as having messages appear in a town map (mostly already done by HTML templates)
• Closing time support (of course)
• Multi- guestbook support, like per page guestbooks, or nigh-day guest books - these can also be collected into a site-wide guestbook to collect all per-page messages etc
• Complex message grouping support, so you could for example show all messages for a two weeks on one page, then then previous two weeks etc.
• Per message CSS support (so guests can style their message)
• Per message iFrame support for webgardens
• Guestbook-Guestbook linking e.g. If I post on your guestbook you can click my name to visit my guestbook
• WAP support for retro phone people
• Integration with ML artifacts and artifact gifting
• Some sort of guestbook games, like each message waters a flower and the flower gets bigger as more messages are posted (Basicly a guestbook level API kinda thing that the books owner can script against, plus a few fun pre-made scripts)
• For ML members, optional participation in one big feed of messages collected from all participating guestbooks, so the messages become a kind of site exploration system like statuscafe
• Embed-my-last-guestbook-comment widget you can post on your site to share your comments
• Weird keyboards, like a T9 keyboard?
• Oh the ability to favourite some messages as a guestbook owner so they appear off to the side as pinned messages you enjoy

[poesu]

any guestbook providers

What I know of are mostly comment widgets, the only one specifically for guestbooks is… Guestbooks. The project was dead for a while, because of stupid Microslop banning the dev for no reason. I'm glad to see it revived, which I've only checked right now lol! Even the messages my old guestbook received are intact. I thought there're lost for good. It's a good FOSS service, but in the same time a cautionary tale of having to at least be backing up your data (on your own devices!), if not completely owning it…

The comment widget providers I used, which can technically serve as a guestbook, are these:

• Giscus for Github Pages sites
• Komments (I find the security measures against account theft insufficient here)

I also see Ayano's comment widget getting recommended, but I haven't tried it, and on Neocities you need to be a Supporter to be able to use it, because security policies for free accounts break the widget.

Must Haves:

For me another must-have is that a commenter does not have to sign up to leave messages! Sign ups of course mitigate some spam, but it's a large turn off for me (privacy concerns too, not just convenience).

EDIT: Guestbooks can be self-hosted! See: https://codeberg.org/meadowingc/guestbooks

[Memory]

The guestbook I have (if your host supports PHP) is this one by PHP Junkyard. It works with custom HTML and CSS (see: my own guestbook). All of the entries are saved in a txt file that's very easy to backup.

There IS a link at the bottom to the original program site (unless you donate), but it's very small and is only at the bottom. No ads otherwise.

[Daniele63]

The guestbook I have (if your host supports PHP) is this one by PHP Junkyard. It works with custom HTML and CSS (see: my own guestbook). All of the entries are saved in a txt file that's very easy to backup.

There IS a link at the bottom to the original program site (unless you donate), but it's very small and is only at the bottom. No ads otherwise.

I tried that one and it works but the entries being put in plain text is not super private, like, anyone can just type the URL to the entries.txt and see people's IP addresses, emails, etc that they typed in, it would be better in a sql database in my opinion.

[Dan Q]

I tried that one and it works but the entries being put in plain text is not super private, like, anyone can just type the URL to the entries.txt and see people's IP addresses, emails, etc that they typed in, it would be better in a sql database in my opinion.

This isn't an inherent problem with storing in a flat file rather than using a database. Storing in a flat file is fine, but you should make sure that, if possible, the flat file isn't in the webroot! There are a few ways this can be done:

1. Put it up a directory! If your website lives in e.g. /var/www/mywebsite/public, put the file in e.g. /var/www/mywebsite or /var/www/mywebsite/data or /var/www/mywebsite/private or somewhere like that. Programs running on your server (e.g. via PHP) can still read files from these directories, but they don't get URLs and can't be accessed directly.

Code

<?php
/* This is /var/www/mywebsite/public/guestbook.php */
$guestbook_entries = file_get_contents( '../private/entries.txt');

...

[font]2. Can't put files outside your webroot? Then maybe tell your webserver not to serve them! You can ban files from being accessed by your web server by changing the permissions on them, e.g. if PHP runs as a user called 'php' and your webserver runs as a user called 'www-data', then you can set the permissions so that the file is owned by php and not readable by anybody else with something like:[/font]

Code

chown php:php entries.txt
chmod 660 entries.txt

Or you can instruct your webserver not to serve that file. How you do that depends on your webserver, but it might look something like one of the following:

Code

# Caddy:
handle /entries.txt {
  respond 403
}

# Nginx:
location ^~ /entries.txt {
  return 403;
}

# Apache:
RewriteEngine On
RewriteRule /entries.txt - [F,L]

Some webservers' default configuration blocks access to certain files or directories: e.g. some package maintainer versions of Apache block files and directories whose names begin with a . by default, so you can just move the file into .data/entries.txt and have it work from there.

Lots of options to work around this unwanted behaviour! A radical third option, of course, might be to encrypt the file (using encryption keys held in the PHP script or an environment variable): that way, it doesn't matter so much if somebody downloads it because it'll be unreadable without the PHP script too! But that's probably not as good an option as the two I've mentioned above.

[poesu]

But that's probably not as good an option as the two I've mentioned above

Why though? I'd like to learn PHP someday, so this thread would be so useful to come back to.

I really hope this is not off-topic…
Edit: thanks for the reply! Makes sense!

[Dan Q]

Why though? I'd like to learn PHP someday, so this thread would be so useful to come back to.

Why is option 3 (encrypt the file) worse? Let's recap the options:

1. Put the file somewhere inaccessible: completely stops the user from downloading it.

2. Tell the webserver to disallow users from downloading it: completely stops the user from downloading it, unless something goes seriously wrong.

3. Encrypt the file: the user can still download the file and can try to break the encryption by a brute-force method or by trying to trick the server into exposing the key; meanwhile the server has to work harder to decrypt the file every time it wants to display the guestbook, and decrypt-and-reencrypt it every time somebody posts a comment in the guestbook.

Encryption's a valid way to protect a file from misuse. But if the alternative is "don't leak the file in the first place", that's a much better option that requires less processing (so works faster) and is still more-secure.

[Daniele63]

This isn't an inherent problem with storing in a flat file rather than using a database. Storing in a flat file is fine, but you should make sure that, if possible, the flat file isn't in the webroot! There are a few ways this can be done:

1. Put it up a directory! If your website lives in e.g. /var/www/mywebsite/public, put the file in e.g. /var/www/mywebsite or /var/www/mywebsite/data or /var/www/mywebsite/private or somewhere like that. Programs running on your server (e.g. via PHP) can still read files from these directories, but they don't get URLs and can't be accessed directly.

Code

<?php
/* This is /var/www/mywebsite/public/guestbook.php */
$guestbook_entries = file_get_contents( '../private/entries.txt');

...

[font]2. Can't put files outside your webroot? Then maybe tell your webserver not to serve them! You can ban files from being accessed by your web server by changing the permissions on them, e.g. if PHP runs as a user called 'php' and your webserver runs as a user called 'www-data', then you can set the permissions so that the file is owned by php and not readable by anybody else with something like:[/font]

Code

chown php:php entries.txt
chmod 660 entries.txt

Or you can instruct your webserver not to serve that file. How you do that depends on your webserver, but it might look something like one of the following:

Code

# Caddy:
handle /entries.txt {
  respond 403
}

# Nginx:
location ^~ /entries.txt {
  return 403;
}

# Apache:
RewriteEngine On
RewriteRule /entries.txt - [F,L]

Some webservers' default configuration blocks access to certain files or directories: e.g. some package maintainer versions of Apache block files and directories whose names begin with a . by default, so you can just move the file into .data/entries.txt and have it work from there.

Lots of options to work around this unwanted behaviour! A radical third option, of course, might be to encrypt the file (using encryption keys held in the PHP script or an environment variable): that way, it doesn't matter so much if somebody downloads it because it'll be unreadable without the PHP script too! But that's probably not as good an option as the two I've mentioned above.

I didn't think of that, that makes total sense! I did do similiar config shenanigans for pointing to my error 404 page, and disabling caching on a specific file (I use Nginx btw). If you're still planning to make your own guestbook, I think I'll wait for that instead of moving to the PHP guestbook, for now I'm in no hurry to swap.

[Memory]

Kind of a bandaid solution but I just blocked off access to the entries file with .htaccess.

Code

<Files "entries.txt">
  Order allow,deny
  Deny from all
</Files>

I can't access it when I go to the file's link.

[grubbyfox]

Heh, this is literally something I've already been thinking about doing! - a free/donation-accepted guestbook system that tries to do similar things to atabook but with better integration options, for Melonlanders and perhaps a few other communities too. And all open-source so anybody can selfhost if they really want to, but available as-a-service for free anyway.

Unfortunately I'm a little bit "out" of the guestbook game and so I'm weak on what-features-people-actually-want out of their hosted guestbook service! What are people looking for?

Ooh interesting! I'd def check it out if you do it. I use Atabook at the moment, and it's fine, it does what it should.

What I'd like in a guest book is a way to actually read/write it within my website, not load over to a completely different website/domain etc. It doesn't feel like a guestbook to me if it's not actually _on_ site/you need to open another site that's not related to yours.

[Dan Q]

What I'd like in a guest book is a way to actually read/write it within my website, not load over to a completely different website/domain etc. It doesn't feel like a guestbook to me if it's not actually _on_ site/you need to open another site that's not related to yours.

Yes! Now that's exactly the direction I'm going in! As of this afternoon I have a basic skeleton and proof-of-concept. I've got more to do before it's ready for people to test/break, but existing features are:

- Log in with a Melonland Passport
- Create guestbook(s) which people can sign
- Configure with custom HTML and/or CSS (optionally on top of a pre-made "theme")
- Three ways to embed! (1) link to it, like atabook, (2) iframe it, (3) web component - that latter one truly embeds it on your website; I've even got a workaround to make it work on places that block cross-domain-fetch, like Neocities; also, it can optionally be embedded with a "fallback", e.g. "embed as a web component unless JS fails/is disabled in which case embed as an iframe unless their browser doesn't support iframes in which case show a link"

Lots still to do before I'm ready to open it up to you fine people, including:
- Spam and moderation settings
- Owner replies
- RSS and email notification (and maybe webhooks, too)
- Import and export

[grubbyfox]

- Log in with a Melonland Passport
- Create guestbook(s) which people can sign
- Configure with custom HTML and/or CSS (optionally on top of a pre-made "theme")
- Three ways to embed! (1) link to it, like atabook, (2) iframe it, (3) web component - that latter one truly embeds it on your website; I've even got a workaround to make it work on places that block cross-domain-fetch, like Neocities; also, it can optionally be embedded with a "fallback", e.g. "embed as a web component unless JS fails/is disabled in which case embed as an iframe unless their browser doesn't support iframes in which case show a link"

omg yay! ^.^ I'm super excited for it! Personally I'd love it as some sort of iframe or whatev, so I can just snag a code and paste it). I'd love to have it as a lil boxy thing on my page, where I could make it as big or small as I'd like and if there isn't enough space in the box to see all messages etc they can just scroll within the box.

I feel like that's such a neat thing with websites, when you can actually interract with things within the site itself