A Bit of a Mix-up 🤷
Back in the early days, before we started developing Quail, I reached out to Stripe's client support about the Stripe Connect model. Since I wanna pay authors like Substack and X do, I asked if a company based in Japan could link to Express accounts outside Japan.
Their response at the time was:
this doesn’t support cross border interaction for Japanese Stripe accounts as of now
As I had asked a bunch of other questions, this answer got buried among many others. Somehow, I remembered it incorrectly. So, although Quail now supports Stripe Connect, It can't pay foreign authors because the Stripe account is tied to a Japanese entity.
Actually, this is mentioned in the official documentation:
Cross-border payouts enable platforms in the US to pay out to Express and Custom connected accounts ...
...
The platform must be in the US.
At that time, I didn't quite grasp how Stripe Connect worked, so I missed this document.
In short, if I want to use Stripe Connect to pay non-Japanese authors, I'd need to go through a US company.
Further SEO Optimization
To enhance search engine indexing efficiency, I've added sitemaps to all Lists. For example, the official blog's Sitemap is https://quail.ink/blog/sitemap_index.xml
However, there is no plan to submit all sitemaps to search engines. Doing so could lower the overall rating of the quail.ink domain if they contain low-rated content.
We need a quality-control mechanism, where only sitemaps deemed high quality are submitted to search engines. This is a necessary anti-abuse measure for the Quail.ink, the online service. But, if you're hosting your own Quail instance, this isn't necessary.
Refactoring and Splitting for Open Source
Speaking of hosting your own Quail instance, let's talk about the progress in open-sourcing.
I spent almost the entire weekend refactoring the current essential code base. The main goal was to separate 'service'-related code from the core code.
'Service'-related code refers to features and infrastructure needed to operate Quail.ink, the service, like multi-regions payments, content operations, service management, finance and tax, etc.
Initially, for simplicity, this code was included in the core service. But, it's unnecessary for self-hosted setups, so I am removing it.
This refactoring and splitting involve the frontend, backend, APIs, SDKs, and I'm almost done with it.
Here's what's left before open-sourcing the core part:
- Hosting static resources directly in the core.
Currently, static resources are split into three parts: a set for static pages and two SPAs, all deployed on CDN.
For self-hosting, you mostly just need the core service to host static resources and maybe add a CDN (though it might work without one), not as complex as my setup. - Enable the core to route requests.
Currently, non-API requests to Quail are routed via a Cloudflare worker. But the self-hosted version can't depend on Cloudflare, so it needs to handle all request routing. - Clean up important
@TODOs.
There are about twenty or thirty somewhat messy@TODOsin the code that need addressing. - Write an installation and deployment script.
Since I'm not familiar with Docker, I plan to write a bash script for installation and deployment.
Fixing Issues
Discord Count Error
This issue has been ongoing for a while. Sometimes, the online member count in the Discord badge would show as undefined.
This happened because Quail was directly forwarding requests to Discord via a Cloudflare worker, but it often hit the Rate limit with increased traffic. So, I added a cache to fix this issue.
Discord Count Fixed
The count won't show errors now.
Editor Page Displaying Articles Not Owned by the User
Specifically, entering the ID of someone else's public article in the article editor would show that article's content in the editor.
This bug didn't pose a security risk. It just displayed public content in the editor. It looked weird, though. So, I've made a check at the webpage to prevent displaying the editor in such cases.
That's the roundup for this week! 🚀📝
