NOWSLETTER is a collaborative tool for gathering events from newsletters.
joelsnewsletters.com is where I put my events, but you could do other things with your data.
This is a way for me (Joel) to stay up to date without platforms. My newsletters have all the info I need, but they are kind of a mess.
This could be useful for anyone collecting events from newsletters, but it works best if you have some connection to the people sending them.
Newsletters are amazing. They're low-tech: anyone can make one. They're not tied to any specific platform. They're entirely decentralised. They're not private, but also not entirely public: they're for a specific context. The newsletter is a dinosaur from an earlier internet, but nothing else checks all these boxes, so they're still around.
Normally we think of newsletters as a kind of flyer, to be read and thrown away. I think they can be a valuable source of data in a local context.
As the admin of joelsnewsletters.com, what I see is a split view where it's possible to compare the newsletter and the result from a local AI. Newsletter to the left and events on the right.
The newsletter author sees the same thing. They can also check and change things, if they want. Usually its me doing most of the work, but not always.
Since we use the same interface, we can collaborate without having to spell things out. They don't need to tell me "please change X to Y". AI does the first proposal, but it's not the final result: AI + 2 humans. Yes, AI is awful. More on that below.
More in details, in 14 steps (slideshow)
You can run this yourself (link below), or I can run it for you. If you are interested, let me know at mail@joelgalvez.com.
You'd need one person who is in the middle, signs up for the newsletters and is the one that oversees things.
After being part of the Facebook exodus around 2018, I missed the comforts of Facebook Events and became interested in the problem of how to recreate that kind of overview. This wasn't a technical problem. It's about how to get the data.
My interest was in finding a method, not in becoming the next hub or becoming a curator. In particular, I wanted this to work at the smallest scale. Someone like me, some guy, should be able to keep up to date with the small places. The big places are never a problem.
I tried various approaches. First, I tried to convince everyone to export .ics/iCalendar files (it worked... partially). It was meant as a kind of budget version of the semantic web, using .ics files. Too much work to ever take off. Besides, you want to know who you're sharing with. I had no intention of "liberating" any data so I felt increasingly uneasy about this approach. It's up to the sender where it ends up, not me.
Second, I tried "scraping" websites. It worked surprisingly badly. A lot of the places I care about barely have websites. And if you just grab some data, you can't tell whether the intent comes across. Checking the quality of scraped data is almost as much work as adding it by hand. It also feels dodgy, since consent is unclear.
Scraping Instagram is similar. It works, but automating the work is an uphill battle. There's also no connection to the sender. Anyway, relying on Instagram is missing the point.
I also tried using publicly or semi-publicly available data. There's a lot of it, and it can be quite good, at least for the places that sell tickets. I was excited about it at first, but I quickly realised that once you use someone else's archive, you're shaped by their worldview. To shape it to my interest I'd need to treat each source differently, and that's too much work.
There is Bluesky, ATproto, Smoke Signal, Mastodon, ActivityPub, Gancio, Mobilizon, etc. These are great technical solutions, but most of the data is missing.
This approach, combining local AI and newsletters is something that passes my own litmus test:
AI can make a rough translation between the sender's intent and my interest. Since I'm using local AI, I can keep an eye on electricity use and there are no privacy issues. The only dodgy thing left is the model itself and the working conditions to create it, but I'm hoping to be able to eventually replace it with something less dubious.
Newsletters are email, so I can just reply and ask: "These are the events I got. Does this look good to you?" This would feel less natural if I were scraping web pages, for example.
These events can potentially be published further via open protocols (Mastodon, Bluesky, ActivityPub, ATproto, Gancio, Mobilizon, etc) or other newsletters and websites.
With difficulty, maybe. At least not as easy as the open web. If you don't want me to have your newsletter, you'll remove me from your recipient list.
If I am the one collecting the data, nobody else gets it. There are no third party services involved such as ChatGPT, Claude, etc.
Each newsletter takes 1-20 seconds, average about 2-5 seconds using Qwen3.6-35B-A3B-UD-Q4_K_XL (Just started trying it out, most mainstream models works fine). My downclocked 3090 draws 210 watts while doing inference.
This means 1000-10.000 newsletters per 1 kWh. I currently get about one newsletter a day. Not negligible, but seem to be going in that direction. Maybe it's useful to distinguish between small/local and big scale datacenter AI?
I've got kinda decent results from Apertus (Apertus-8B-Instruct-2509-Q8_0), a fully open and reproducible model trained on transparent data. I can't run their 70B model, but judging from the progress I'm guessing that I could soon rely on a model with transparent training.
Yes. Server (Web server + incoming email), client (LLM jobs, talks to llama-server). If you run into issues with setting things up, let me know.
mail@joelgalvez.com