Hugin is searching for a replacement of Google Groups

Hugin is searching for a replacement of Google Groups:!topic/hugin-ptx/mEePHXFVbYI

@patdavid I think could be a solution, but perhaps someone with more technical knowledge can help them .

1 Like

The way I’m reading it, it’s not that Hugin is searching, but more that one Hugin user who hates Google is searching.

Most specifically, it does not appear that the active Hugin developers support such a move. In fact it looks like Bruno pretty much explicitly NAKed the idea of moving to Discourse or anything else web-based.

People were saying that Discourse tracks you around the web.

Is this backed up by anything?

where are they saying that?

and are you sure it isnt “disqus” you are talking about?


At least at, I don’t think that is true. The site loads a few images from, and a CSS file from Cookies are only set from Other sites may configure Discourse differently.

AWS is because we store all the post images in an S3 bucket.

Google API is for fonts… Maybe we should look at getting rid of that.


Yeah, I’m blocking access to the fonts (with uMatrix) and I don’t really miss them. Using an S3 bucket for images makes sense.

See GnomeNomad’s post.

It seems that he was unable to back up any of his claims though.

1 Like

Yikes that looks like a long thread. I’ll give it a read on the plane tomorrow (too busy packing at the moment for a short trip to Charleston, SC).

Of course we would love to host the forums for the Hugin folks.

When I get time I’ll head over and craft a response in that thread to directly address any concerns and make the offer. Who is the main dev on the project at the moment that might be in a position to approach about migration?

Generally, we don’t track anything outside of what default Discourse does and a snippet of Piwik/Matomo analytics. The thing is, we own the entire stack (@darix manages the Discourse install here and @andabata runs the servers for + matomo analytics). I do actually have a note to remember to remove the google-hosted font files so I will do that soon.

We pay for the hosting through donations (both money and time/effort). I said it four years ago and it’s still true. No ads, no thank you. I’d rather just continue paying out of pocket indefinitely if I had to (luckily I don’t thanks to the awesome comunity).

I also notice that many folks concerns about these types of communications channels is that they hate using a web interface and prefer to use their mail clients like a traditional mailing list. We can do that too. I can even turn on the ability to start a post in a category directly from an email (I don’t think we have that turned on anywhere yet).

I am of the opinion that it enriches all of us when we can have other Free Software projects and users in close proximity.

Ok, if I haven’t answered in a day or two please someone poke me or mention me in this thread again to make sure I reach out.


I believe Bruno Postle is the primary developer, and he’s obviously pretty heavily against the Discourse approach.

Also, you might want to read some of the other comments, such as Jim Watters’ comment of “no overhead in the body of the messages” - which sadly is something I’ve found that Discourse is guilty of.

From reading the thread, I think you’re going to find this to be a very uphill battle. It looks like nearly everyone but the person who originally proposed it (who is, as far as I can tell, not a project developer) pretty set against it.

Among other things (one issue of which was hinted at in the discussion): What about edits? These are common in web-based forums, but basically not possible with any email system. As a result, usually people on email lists adapt their conversation flow to that limitation. But what happens when someone here edits a post?
If all email subscribers are notified, that’s been established in the linked thread to be completely unacceptable to the Hugin team and the majority of their users
If no one is notified, you potentially have a post on the web that is completely disconnected in content

While in theory Discourse supports email-based I/O, I’ve found it to be fragile enough that the Hugin team will likely reject it as an acceptable replacement. I see posts every week or two on various Discourse forums where chunks of the email body overhead got mixed into the reply message of a forum post. (Which is why I treat the email functionality purely as a notification - unlike the Hugin team I actually prefer the forum approach. It tends to be easier to “catch up” after a long break.)

1 Like

It doesn’t hurt to offer. I’ve offered several projects and been turned down. No big deal.

1 Like

True… It just doesn’t look to be promising. The biggest potential issue I see is that the assertion made in this thread’s title (Hugin is searching for something) is very different from the reality I see on that particular linked thread (One Hugin user is searching for something because they hate Google, but it sounds like the core developers are not.)

except the only URL in this thread with regards to discourse is a link that explains that they aren’t tracking any data?

also that GnomeNomad is quite uninformed and just grumpy about any change. did you know that discourse has an awesome mailinglist mode so you can read the forum via email as well?

so right now I will just say all that was useless FUD.

What is the worry with Google Fonts? They use a different domain specifically so you cannot be tracked by your Gmail or other Google login. They do not use cookies, so the best they could do for ID is your IP address + User Agent. And, they’ve said they discard data, like User-Agent, unnecessary for serving the fonts.

The only data Google could have on you is your REFERRAL header. (Isn’t there JavaScript to fudge that?) Anybody who cares about such tracking will likely have PrivacyBadger, making it a moot point.

I just don’t see Google bothering to surreptitiously track essentially anonymous access to their fonts API when people are clamoring to log in and willingly give up all their privacy. It’s just too much effort for poor quality data.

Here’s a snippet from the Google Fonts FAQ:

What does using the Google Fonts API mean for the privacy of my users?

The Google Fonts API is designed to limit the collection, storage, and use of end-user data to what is needed to serve fonts efficiently.

Use of Google Fonts is unauthenticated. No cookies are sent by website visitors to the Google Fonts API. Requests to the Google Fonts API are made to resource-specific domains, such as or, so that your requests for fonts are separate from and do not contain any credentials you send to while using other Google services that are authenticated, such as Gmail.

All the same worries that I have with google. Their ToS/EULA is lawyer-speak, and I’m sure they do whatever they want with that data.

1 Like

Heh. Fair enough. I copied any Google fonts I use onto my own server, myself. I just wondered if there was more than my own paranoia to justify it. :wink:

You need to be mindful of the license of each font.

All the fonts on google fonts are freely licensed.

I mean, if one were to make a copy, would one need to copy the licenses as well?

Usually the license goes with the source code, not (always) with the distributed binary.

1 Like