Show HN: Privacy-first, minimal, fast blogging/newsletter platform
papyrus.so
papyrus.so
At the start of this year I set a personal goal to blog more. I wanted to 1) improve my writing skills, 2) build an audience, and 3) if the stars aligned, start earning a bit of supplemental income via paid posts or subscriptions.
I looked at the existing blogging/newsletter solutions out there, and none of them quite fit what I was looking for. They had paywalls (Medium), features I didn't need (Wordpress), too minimal a design (Buttondown), lacked transparency (Substack), or cost money even when I wasn't earning yet (Ghost).
So, I built my own.
No trackers or tracking cookies are used (beyond Plausible, for privacy-preserving analytics). Speed and minimalism is a big focus: all blogs are rendered as static HTML, using as little JS as possible.
You can write blogposts in markdown, publish them, let your readers subscribe, and (when you're ready) connect your Stripe account to start charging readers for access to paid posts. You also always maintain ownership of your posts, and you can export all data at any time.
Still in the early stages, so any feedback would be great.
Thanks!
I might actually use this. Simple and effective and not full of crap. It could use a little bit more documentation (inter-post linking how? hardcoding might be fine, but it'd be nice if that link-popup searched your post titles or something) and probably a small bit of extra flexibility... but finding the balancing point between "feature-full" and "simple" is quite tough, as is keeping it fast. I'm pleasantly surprised with it as-is.
Any chance of custom domain support? I assume that would be a paid feature (it always is, I think that's reasonable), but it is nice to have that option. Also RSS.
I invested quite a bit into speed, and thankfully Next.js has a lot of great built-in support to make things fast - incremental static regeneration, link prefetching, image optimization, etc.
For the editor bugs - thanks for highlighting, I filed a bug and definitely hoping to tackle this eventually.
Agreed on the documentation as well - it's on my radar to improve.
For custom domain support and RSS - both features on the roadmap! Likely RSS first, as that's quite a bit easier to implement, and custom domain support shortly after that. (Custom domain support is probably the #1 feature request at the moment).
Thanks again for the feedback!
This will happily fill the gap and let me get something 'out there' and find my niche while continuing to be indecisive about self-hosting.
Pretty darn frictionless setup, nice clean look and feel. I like it so far.
One thing I would say is that your top navigation bar (for example clicking on 'Why Papyrus?') doesn't appear to work without JS. I hope the rest of the website experience is not hindered by the need to run JS.
We're still in the early stages so no large blogs to show just yet.
Here's the Papyrus blog, if you're more curious to see how a demo blog operates: https://papyrus.so/@PapyrusBlog
And thanks for the tip about the JS issues - I'm absolutely focused on making the entire site accessible without JS, so this is important to me. I'll take a look at shortly.
Maybe I'm wrong and you did the math.
The urls for sharing buttons are below.
https://www.facebook.com/sharer/sharer.php?u=https://papyrus...
http://twitter.com/share?url=https://papyrus.so{router.asPat...
1. I noticed that the signup email comes from papyrus.dev instead of papyrus.so. Any reason in particular for using 2 domains for the service?
2. Do you plan to support adding third-party tracking JS for services like Google Analytics, Umami etc?
3. I also shared some feedback elsewhere in the thread, not sure if you saw it: https://news.ycombinator.com/item?id=29083365
2. I'm not sure yet. One of the selling points is no third-party trackers, so I'm not sure how readers will feel if some of their blogs started tracking them.
3. Thanks for the feedback, and I appreciate the mockup! Agreed that section can be clearer - I've added this to the backlog.
If you ever want to use a ccTLD, I recommend starting by looking at the registration restrictions in the infobox in the ccTLD’s Wikipedia article, e.g. https://en.wikipedia.org/wiki/.so says “Limited to institutions and organizations in Somalia, residents of Somalia, others who have a legitimate, clear and provable connection to Somalia”. Also consider whether you trust the country in question to operate its registry well, not to have hostile takeovers that mess up the entire thing, &c.
Generally speaking, I recommend avoiding using ccTLDs in this way. Even new gTLDs are mostly safer. One possibility there is papyrus.pub (“pub” being nominally short for public houses, the eating places and such, but also definitely being used for publishing).
I have seen about three other .so domains, notion.so being by far the best-known; and Notion has definitely had trouble at least once either with their registration or with the operation of the registry.
[0]: https://papyrus.so/@PapyrusBlog/how-we-reduced-next.js-page-...
These figures are in no way light (even if they’re lighter than far too many sites). Given the positioning and the statement “as little JS as possible”, I was definitely expecting less than 5KB of JavaScript, perhaps even nothing beyond Plausible; having seen SPA functionality I’d be willing to increase that expectation to 25KB.
I’m with topicseed: Svelte would be a much more sensible starting point when seeking to use such a framework; SvelteKit can give you the same style of SPA stuff.
One last batch of remarks: most of the stuff in the “optimise images” step of that article is counterproductive. General content should not attempt to use lazy loading, it tends to make the experience worse, especially for distant visitors with higher latency but normally it doesn’t even help things for low-latency viewers. (next/image is wrong and foolish to enable lazy loading by default.) In the case of the logo specifically, if that’s the quill, that looks like it should be SVG—smaller and faster. And <code node="[object Object]">…</code> as the translation of the Markdown `…` is probably a bug.
it's a pity I can't get paid, because Stripe is not available in my country. Maybe add some other options, such as Paddle, to those of us who are located in Africa where Stripe is not available yet.
This definitely sounds like a bug.
At $5 per blog, I can’t justify subbing to more than… 2 at the most.
Compare the value proposition to something like Spotify.
I imagine there will be months when I don't write anything. Why would somebody still subscribe.
Looks stellar btw.
Maybe you shouldn't be selling subscriptions for your writing if you're not actually writing?
The service is free and only takes a 5% of subscription fees when they are active.
I made a quick mock up: https://excalidraw.com/#json=5965784438276096,bD8ptwUwiZX9o0...
All the best OP! We need more services like this!
Maybe you should provide more links to existing blogs somewhere? (e.g. something like https://read.write.as which aggregates public posts from blogs on write.as)
Yes, I've been meaning to do this - I haven't prioritized it yet because we have not had enough quality blogs on the platform to showcase, but after all the HN traffic I think this will change :)
This is something I'm actively working on. I've already begun to implement functionality to import subscribers from Substack (you can test it out in the /settings/blog page).
After I finish Substack, I'll begin adding support for importing posts/subscribers from other platforms.
FYI – All of your site pages have the same title, or are missing page titles.
And thanks for that -- should be fixed now on a majority of pages.
The editor is currently markdown combined with a rich text UI-based editor. I haven't explored supporting other types of editors (beyond extending the UI), but I'd be open to it.
What I’ll often see however in Markdown is a lot of handwritten HTML to accomplish this stuff which kinda defeats the point of a lightweight markup language. There’s also a big list of typographic substitutions which is nice for authors that prefer to type in ASCII but want proper quotes, dashes, arrows, etc. These are all things I would want if writing technical content where I am in control of styles and demand good typography.
Does this work in any country, or just one?
What do you mean exactly by this?
https://thehypothesis.substack.com/p/heres-why-substacks-sca...
https://doyles.substack.com/p/in-queers-we-trust-all-others-...
https://www.vox.com/recode/22338802/substack-pro-newsletter-...
The TL;DR is that Substack has allegedly paid large sums of money to bring writers onto their platform. The writers they've paid have historically been on one end of the ideological spectrum, and Substack has not been transparent about who is being paid, nor how much.
That's what I call minimal. Unfortunately it's linked to Hey email service which I'm not using
For my own curiosity -- would you blog more often if someone offered you cheap(er than ghost.org) hosted ghost instance from which you're free to take your data any time?
[EDIT] - To make it more concrete, let's say someone gave you a ghost blog that was free with a soft-capped at 100 visits/day (and $5/month after)
By capping your tiers at number of users you are losing a lot of people who might otherwise use your platform, imo.
Here's my reasoning:
You need to get lots of users to market to so that you can convert those users to paying subscribers. Getting people to sign up for notifications is one thing, getting them to pay money is a whole other proposition. The former is pretty easy and the latter is not. Forcing people to try and do it all in one fell swoop for fear of reaching an arbitrary "user limit" is not reasonable.
The hardest part anyone trying to do this from scratch is going to go through is getting off the ground from a handful of users to a few thousand users. Once they've gotten to that point, and can convert a few hundred of their few thousand users into paying subs, they're getting closer to seeing light at the end of the tunnel. The most feasible way for them to do so is market to their free subscribers / free followers with premium content, engagement with paying subs that they're missing out on, etc.
Ghost chops the legs out from under them when they get to the first hurdle with the 10,000 user limit.
I understand that database costs and email / SMS sending are the expensive part of hosting and have built content distribution backends before, so I get it. I understand the reasoning of putting the limit on pricing tiers there, but it would seem that a more flexible way is in order in Ghost's case. If we presume that you can convert 1% of free accounts to paying accounts, Ghost's pricing page tells its prospective users that they are going to be stuck in a $500.00 / month hobbyist income tier forever.
Maybe it's better to just do a single no-bullshit price and run unlimited ghost instances for people -- and once you know the scale that a particular instance can take, different tiers for the very large instances. Maybe one price (let's say $10) + custom? But at this point you'll be overwhelmed by users with very large followings which generate tons of traffic.
And if you go by a strictly bandwidth model, then people are vulnerable to overages...
I think if you're trying to cater to paid tier users, segmenting users by free/paid and only serving free tier users the cache without any sort of interactivity features is the first thing (no comment posting, no upvoting / downvoting, etc).
Finally, yes, I think the scaling cost has to be passed on to the site owner, I don't think you can shoehorn a very elastic service in terms of hardware / network demand into a fixed monthly price, without subsidizing successful users on the backs of those previously mentioned hobbyists.
Lastly, on a more philosophical level, I think media producers / publishers need to get together and stop nipping at the heels of Facebook, Twitter, Google, Amazon, and Apple like puppies following their masters around. I mean, the whole newspaper industry let itself be duped into poor staffing decisions by Facebook lies about video metrics. Which is funny considering Facebook's whole business model is taking other media businesses' ad revenue and keeping it for themselves. I guess media execs never heard the one about grandma and the big bad wolf in their MBA programs...
Obviously can't speak to the back-end since it's not open source so there's no way to know what metadata it's recording, but there's no email verification required so as long as you can remember your login details, it won't necessarily link back to you - pending IP addresses etc.