strnisa

I believe the idea has been attempted many times before, primarily by large companies that have tried to create their own currency. It seems deceptively simple, but it's quite tricky to get right, both from a legal and technical perspective. One of the main legal complications is the one mentioned in another comment: avoiding the status of an e-money institution.

With Small Transfers:

  - There is no wallet or funding for the account. Customers simply pay for what they owe, usually at the end of each month.
  - There is a lower psychological barrier, since there is no subscription or prepay commitment. Customers who dislike recurring payments are more willing to try something new that avoids this.
  - Merchants need to introduce customers to just one extra service, Small Transfers.

Some customers of Unattach (a service I built) are happily paying for the service via Small Transfers, and early feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model.

As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.

Ultimately, the merchant bears the risk of non-payment, but the platform does its best, using industry-standard practices, to pre-check the customer and their payment methods for fraud and ensure a successful payment.

If a merchant successfully authorizes a charge, the amount is reserved for that merchant for a limited period. Trying to capture that amount (or less) during this period will succeed.

Yes, Small Transfers can be used for pay-per-view or pay-per-minute billing models.

The platform's biggest risk that I see is a customer defaulting after using a merchant's service. The platform currently mitigates that with Stripe Radar, 3-D Secure, and spending caps, but I'm keen to hear anything specific you're thinking about.

Thanks! Small Transfers uses its own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.

You're right to consider this, as it's an important aspect from a legal perspective.

Since Small Transfers doesn't store customers' funds or allow them to withdraw a balance, the platform is not considered an e-money institution or a "wallet".

When the customers pay their balance, we immediately forward the funds to the merchants.

Regarding notes on Apple Podcasts, I guess you're referring to an introduction teaser for each episode? The major benefit of of PodSnap.AI summary is that it contains the key insights within the episode, as well as an overall summary.

Regarding copyright infringement, the service is not republishing other people's work as its own. This is equivalent of someone writing a blog that contains podcast summaries, except that the work is done by AI. Also, the website only uses publicly available information and links to the originals where appropriate.

Thanks! I completely agree that listening/watching a podcast episode is best. However, with so many great podcasts, it's hard to prioritize. PodSnap.AI gets you quick summaries for all of your favorite podcasts, so you can easily decide which episodes you'd like to listen to.

Thanks for sharing this info! I'll look into it.

Yes, various details depend on the tax juristiction. Thank you for pointing out UK specifics. In the UK, there are also ISAs, which can be used to reduce tax on investments.

For example, accumulating ETFs make sense in many EU countries, because often there is no dividend allowance and so dividends just gets taxed as income.

Several countries also have a system by which the capital gains tax decreases with the length of the investment, which means that accumulating ETFs make even more sense in that case.

In the real world, code is read often and for many reasons. The main ones I can think of are:

    1) To understand the system without necessarily wanting to change anything. This is common with new employees or anyone wanting to learn more.
    2) The system often needs tweaks, bug fixes or new features. Each of these normally requires that the code in question is read by several people several times.
    3) The architecture is normally not perfectly modular, so changing one part often requires one to understand and tweak the neighbouring parts of the system, too.

The real mistake is not correcting a mistake when you see you've made one.

It's always hard to let someone go, especially in a small company with a focus on personal development and a positive work environment. However, if you don't address this situation:

  1) The morale of the company will likely decrease.
  2) The productivity of the team will suffer.
  3) Employees may start questioning the leadership's decisions.
  4) Some may consider leaving as a result.

Generally speaking, the well-being and efficiency of the entire team should be a top priority for the company. From this, it also follows that having a solid interview process is crucial.

The standardization of medical alarms was important when introduced, providing consistent and clear communication across devices and countries. However, with modern technology, these standards may now limit innovation.

It seems to me that clear verbal alerts like "BLOOD PRESSURE VERY HIGH" could be more immediately understandable than tones. A hybrid system combining verbal alerts with alarm tones might be a good compromise for clarity and international usability.

Coincidentally, this is also the future hyperloop map.

This optimization exercise still assumes that a bunch of variables are constant, e.g. berthing slots at ports, port operational schedules, ship speed vs fuel consumption, etc. It makes me wonder how much more efficient the system as a whole could be, for companies, consumers and the planet. (Disclaimer: I'm not in the shipping business.)

Thanks for all the improvement suggestions! Taking them into account, the `makeSlug` function becomes:

    function makeSlug(length: number): string {
        const alphabet = "0123456789abcdefghjkmnpqrstvwxyz";
        let result = "";
        for (let i = 0; i < length; i++) {
            result += alphabet[crypto.randomInt(alphabet.length)];
        }
        return result;
    }

I've become a fan of unique, relatively short and "human-readable" IDs, such at the ones used by Stripe, e.g. `cus_MJA953cFzEuO1z` for an ID of a customer. Here's a Stripe dev article on the topic: https://dev.to/stripe/designing-apis-for-humans-object-ids-3...

If you use JavaScript/TypeScript, you can make them like this:

    function makeSlug(length: number): string {
        const validChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
        const randomBytes = crypto.randomBytes(length);
        let result = "";
        for (let i = 0; i < length; i++) {
            result += validChars[randomBytes[i] % validChars.length];
        }
        return result;
    }

    function makeId(tableName: string): string {
        const idSpec = TABLE_NAME_TO_ID_SPEC[tableName];
        const prefix = idSpec.prefix;
        const slugLength = idSpec.length - prefix.length - 1;
        return `${prefix}_${makeSlug(slugLength)}`;
    }

I think that the UK one (https://www.gov.uk/) is generally very good: everything in one place, relatively simple UI, good overall structure.

Hi HN! The author of RoboGPT here. AMA.

Robo-GPT is a simple and extensible program that helps you run GPT-4 model autonomously. It is designed to be easy to understand, so that anyone can use it and extend it.

The program was inspired by some of my earlier research and Auto-GPT.

I tried to make the code clean and dependencies simple. It currently doesn't have as many features as Auto-GPT, but is hopefully easier to understand, run and update.

Looking forward to your feedback. Also, feel free to run it yourself, make change and/or contribute.

SEEKING WORK | Remote Only (based in Europe) | Part Time

Generalist software engineer / tech lead / manager.

12+ years of experience.

Added it to the blog post.

The author of the blog post here. AMA.

Hi LightG, author of Unattach here. I'm happy to hear that you're considering using the app.

Regarding scale, practically all of the work is done within the user's browser; the server is used only for downloading the app, auth, admin and metrics.

Please see my answer to this above (https://news.ycombinator.com/item?id=32467052).

Disclaimer: I’m the author of the web app.

The web app needs write permissions to the user’s Gmail account. In such cases, Google requires the author to explain how the permissions are used, submit a video showing this, and ideally to have a reference from someone working at Google.

Thank you for the kind words. I'm glad you found my web app useful.

> Nice app. I'm forever running out of Google One storage and didn't realise this was possible.

Thanks! If you give it a try, I'd be interested to hear your feedback.

> 'Fortunately, I've created a web app called Unattach that solves this use case.'

I actually had this exact phrasing in the draft version of the blog post, but was advised by some against using it, because "it's standard practice not to include attribution on these types of blog posts." I've now added it back.

> Also, please consider left aligning your text as dyslexic people struggle with justified copy.

Ah, I wasn't aware of this. Just changed the whole blog post to left aligned.

Apologies, added a disclaimer now.

The app will soon support the ability to back up the whole original email (in .eml format) before any changes are made, should the originals be needed for whatever reason.

I've just tried doing this with Mutt. It's quite awkward, but (after fidling with the interface) it did create a new email with an empty attachment, i.e. the attachment is still there, but it has zero bytes. Also, the original email remained within Gmail. So, it seems that Mutt doesn't work well with Gmail for this use case. (Disclaimer: I am the author of the web app Unattach.)