Campfire: Web-Based Chat Application | Hacker News Reader

Campfire: Web-Based Chat Application

github.com

75 pointsthunderbong30 comments

Open articleView on HN

Reading through some controllers and models, haven't encountered a single code comment yet, just chiselled-out ruby.

Arbitrary examples:

https://github.com/basecamp/once-campfire/blob/main/app/cont...

https://github.com/basecamp/once-campfire/blob/main/app/mode...

Reminds me of Ash (Elixir framework).

Seems great on paper, but quickly turns into a nightmare. Magic is great to get you up to speed, but as soon as you find yourself having to bend the magic, good luck.

There's not much magic in any of these. Scopes for example are just a convenience on top of a self method that can be chained to spit out SQL.

Make sure to tell the team about it, and ask questions about it. Sometimes it's hard to tell the difference between magic and a misunderstanding

I got a kick out of seemingly server-side browser blocking https://github.com/basecamp/once-campfire/blob/eecdb29332527... without one iota of "but, why?"

I dont know for sure why but could it be that they are using importmaps and so it needs some browser versions to support it out of the box.

One the other hand there is an advantage to use importmaps removing the dependency on nodejs for FE assets thus making both DX and deployment a breeze.

(a) reasonable guess, but it seems no, given https://caniuse.com/import-maps cites FF 108(!) versus the forbidden 120

(b) ok, fine, then include any english anywhere (in the source code, in the incompatible_browser.html.erb, in CLAUDE.md, whatever) so future generations would have any sane reason to mutate those magic numbers

Could it be that they removed /all/ comments from the codebase when they made it public, to not release some sensitive information that was in them?

possible, but I've worked in similar sized codebases that didn't use them intentionally (linted them out)

the idea being that the code should be readable enough to not require then

We're a Ruby shop and we have pretty much zero commented code. Ruby's intended to be readable enough not to need them and when we do need them, it's a sure sign we need some refactoring.

It's Ruby. No amount of comments will make somebody who doesn't grok Ruby understand the code.

Crazy how early they were with this, how talented the tech team, and how poorly it did. Would love to read a post mortem on what went wrong.

I recall it being slow, with frequent downtime, poor mardown support, and having very poor (or nonexistent? can’t remember exactly) first party non-web clients. I vaguely recall some third party apps picking up the slack (pun!), but integration was pretty basic (they did their best).

It basically stagnated like it was abandon, and then hipchat (atlassian bought and killed it) and later slack just ate its lunch.

As DHH would say, Luxury languages are good for development.

A demo/playground in the readme would be very helpful

There's a Dockerfile and instructions on how to build it.

hmm.. not really. The dockerfile is for production, and to run locally in dev requires manual installation of ruby and redis, for someone without ruby installed this could easily be ~1h. (glad for any corrections)

The quickest way for a non-rubyist that I can think of would be:

- Install rbenv

- Use rbenv to install ruby 3.4.5

- Install and start redis

- Clone campfire repo, run the two lines in the readme: bin/rails setup && bin/rails server

- go to http://localhost:3000

Note: depending on your OS sometimes installing rbenv and ruby require a few other dependencies to be installed. E.g. ruby-build on macOS, which is easily installed with homebrew.

Would be awesome if the dockerfile could be harnessed so it could be used in development, not just production, so all the above steps would be unnecessary. (this would make it easy for non-rubyists to demo rails apps generally, not just for campfire but all apps that we want to allow others to run locally and play around with).

I installed it with docker, it was easy. I haven’t tested it in a real deployment with real users, but I could easily test it myself, starting the server from my laptop.

You clone the GitHub link, then `cd` there and run docker:

   docker build -t campfire .
   docker run \
     --publish 3000:3000 \
     --volume campfire:/rails/storage \
     --env SECRET_KEY_BASE=$(docker run --rm campfire bin/rails secret) \
     --env DISABLE_SSL=1 \
     campfire

Before that, you need to add yourself to docker group (and reboot):

   sudo usermod -aG docker $USER

Otherwise, the command fail as it needs sudo rights for generating a secret. Or you could generate the secret before that:

   sudo docker run --rm campfire bin/rails secret

And then insert the long string into your command, after `SECRET_KEY_BASE=`.

I did all that on Linux, so I have no idea how to do that on macOS.

As a final step, you visit either localhost:3000 or ip-addr:3000 and play with the chat.

With Colima, all the above worked for me on a Mac.

The bigger news is that it was open-sourced

https://x.com/dhh/status/1963675999012552970

We had a similar project called chatti.ly (like merrily merrily merrily)

https://github.com/plasmatrout/chattily

Then slack came…

Thx a thousand times. Once is definitely a cool thing, for people learning how to code, for small companies that could pay one time with no monthly fees

C00l

dupe filtering is evidently just just a lost cause here

- https://news.ycombinator.com/item?id=45126432

- https://news.ycombinator.com/item?id=45132968

---

and the reason why duplication jams me up is that all 3 have comments on them, that each of the 3 audiences who stumbled upon their individual submissions won't see

> More info about Campfire: https://once.com/campfire <https://news.ycombinator.com/item?id=45128162>

> Too bad they didn't say "here's why not (Mattermost|Zulip|probably 15 other ones)" <https://news.ycombinator.com/item?id=45134447>

although that last one was kind of addressed by the once link because in its FAQ is "we don't care about your other platforms" so the answer is "because NIH is awesome"

> although that last one was kind of addressed by the once link because in its FAQ is "we don't care about your other platforms" so the answer is "because NIH is awesome"

The 37Signals (now Basecamp) company found a lot of success in the past by creating simple web tools and then marketing them hard into new (at the time) marketing spaces like podcasts and social media. Using small company 37Signals products instead of corporate Jira was viewed as forward thinking, rebellious, and the superior choice in some contexts. DHH (founder) was constantly stirring up controversy and clickbait and leveraging it as marketing. I actually saw it more from people in non-tech companies, some of whom would boast about using 37Signals tools as a sign that they were keeping up with technology trends.

I tried using their tools multiple times over their early years but never felt impressed, so I always migrated away. They were the kind of company that was highly opinionated, didn’t care how other companies did things, and didn’t care how you wanted to use the tools. They built what they built and they were going to gaslight you into believing you didn’t actually want the features they didn’t have (until they implemented them later, of course). For people who hung on DHH’s every word this all seemed eminently correct, but all of the DHH and 37Signals fanatics I knew eventually had some break where they realized there was more to the world and that other tools were actually very good and often better.

As for this tool: I think they just have enough success and cash that they can build whatever they want and have fun. If the past trends hold, they’re probably trying some reality distortion field marketing to convince users that other platforms are bad for some reason and you don’t actually want any of the features that they haven’t shipped in this product (until they ship them, at which point they become great).

I was interested in this chat and installed it locally, to test. That was super easy with docker. It works, it looks like it works well. It doesn’t have any notifications on my iPhone, it says I should enable them in the settings, but I couldn’t find where exactly, there was no Campfire as they say. It is so simple, the chat, that I expected it to work on an old iPad 3 with iOS 9.3.5. It doesn’t. I’m not surprised, and I don’t expect it to work. All I mean, it looks so simple, I thought I won’t be too surprised if it would work with the obsolete Safari.

Surprised to see four same links over the week, but all of them have just one comment. Aren’t people not even remotely interested in the app? Not even investigate the code, huh?

I think using importmaps might be why it is restricted (see https://github.com/basecamp/once-campfire/blob/main/app/cont...) to some browser versions.

One can try to migrate it to vitejs for example or any other JS/CSS build tool and it might have good chances maybe to work on older browsers.

> Aren’t people not even remotely interested in the app?

Could be extremely useful to many communities given (free) Slack no longer stores messages beyond 90 days.

Please, no. Zulip offers free hosting for open source communities and they also have publicly browseable archives, so information doesn't go into chat black holes to die

Also, no one needed Yet Anther Self Hostable Rails Chat Gizmo, so if those communities were previously on Slack then their lack of remediation was inertia, and not lack of options

After exploring this chat, over the weekend, I had some impulse to explore other alternatives. Namely, Zulip, Mattermost, Rocket Chat.

I was impressed they all are crippled for self-hosted version. They ask unreasonable price for organisations. One of my colleagues, they have an organisation of somewhat 50…100 people, but their work isn’t with computers even. So half of the employees are going to check the messages from their mobiles. They use whatever everyone uses, WhatsApp, Facebook Messenger, Telegram. I thought of offering them some managed (by me, plus other nerds from the company) instance.

Yet, Zulip allows only 10 people mobile notifications for free. Otherwise, it’s $3.5 a month, per user, so I assume that would be $350 a month per 100 users. Even considering 75 of them won’t chat 99% of the time. They might receive some short messages during the day and ‘OK’ them. Not that it’s too much, but it’s $350 a month for those 25 managers, in perpetuity. They can use whatever else for free. (I know, privacy, but most people don’t understand and don’t care.) I guess that was the pitch for Once Campfire as a product. You pay the price, $300, once, and it’s yours. You deploy it, and you have your little company chat forever. Instead of paying the same price monthly. For a less-than-250 employees company (which is most companies, I think), it should work off the relatively cheap Digital Ocean / Hetzner droplet. Or even a real server (a Mac Mini?) in the office.

Mattermost nags you to buy their Enterprise offering, it’s everywhere in the interface. Again, it’s 10 a user a month, and for the 100 heads company, it’s just a ridiculous $1K a month.

Rocket Chat has a bad history, according to very brief research. So I don’t even consider them.

I don’t like this pitch that managing a chat is a tremendous chore. For some companies, it’s not like some life-and-death situation. In the example I gave, when a company uses some third-party free tier (Slack, MS Teams, whatever) or even a public messenger (WhatsApp, Facebook, Telegram), they can easily return there if their primary one is broken for some reason. But in reality, I expect once deployed, this thing needs backups and just works most of the time. And does not ask a ridiculous price to pay.

Reply on news.ycombinator.com