Hacker News Reader

Hey Hana & Josue, congrats on the launch. I like your approach of how to integrate it into products (via native React libs). I think you could go even a little bit further. One concern I would have is that by using your react library, I also bring in a new state management (mobx). In our case it would be fine, because we are using it already, for others it might be an issue. The most extreme version I found is from feedback.fish, which gives a native react component, but internally imports their scripts still in an iframe.

The other thing would be, that the react package could export not only hooks to interact (useMagicBellEvent), but also provide some hooks or headless components to easier integrate with existing UIs. Something like this is very important to all external services we bring in, because our Product Design should feel like one.

This is really good feedback.

1. We are going to remove Mobx. It will also reduce the learning curve for our customers. This change won't affect our API and will be fully backward compatible. We are considering Valtio as an alternative [0]. 2. As much as we can help it, we are not going to embed iframes. We'd love to deliver a native, and lean experience. 3. We already provide a network layer library [1] and want to offer more headless components. Can you give us some feedback on what you'd like to see? We are very inspired by Downshift's approach [2].

[0] https://github.com/pmndrs/valtio [1] https://www.npmjs.com/package/@magicbell/core [2] https://github.com/downshift-js/downshift

Building notifications multiple times made me appreciate this, so, so much. Even larger companies have trouble with notification. One of my worst nightmares is notifications from Reddit and Airbnb (sorry TommyDANGerous). I hate it when email, in-app, push don't sync.

Some thoughts: You are pricing per monthly active users, but there may be sites/apps that ping users all the time, and others that may do it far less frequently based on specific actions. It may help to break down pricing by number of notifications rather than active users.

Thanks for the feedback. We keep track of all the feedback on the pricing.

There are a couple of reasons to price based on the MAU. Unlike services like Sendgrid that route an email and then forget about it, we have to maintain a persistent connection for every active user (while they are in your app) and support an API to fetch and show them their notifications. Second, a lot of people don't know their notification volume. But like I said, definitely listening to all the feedback and open to figuring out better pricing models.

That's interesting. What's common from what you observe? Notification per user per month wise?

In our early customers, there is is a wide range. As we get more customers we should have a better sense.

We do this with Notifly.io

Congrats on the launch Hana, Josue!

This product makes so, so much sense. I can recall at least 3 times over the past few years when I've had to build some version of this for my projects and would have loved to use MagicBell.

If you're able to share, where have you found initial growth? Has it been on the early stage startup side / enterprise?

Also, small typo on the pricing page "engineerrs" in the Business tier.

All the best

Thanks for catching that typo. Pushing up a fix now.

We see traction with early and later-stage companies, but the bigger orgs take their time to launch since they usually need buy-ins from at least a few people - developers, designers, and product managers. We got some interest from big enterprises, but I need to get better at working with them over the long-drawn process!

Quick question regarding frontend integration. I see that you can embed a widget that requires an API key and the currently authenticated user's email. Does this mean that if I'm a malicious user, and I edited my local Javascript to swap the email with another user's email, I could view the other user's notifications?

There are two ways to handle that. One is to use your external ID, if they are UUID or something random. That's security by obscurity.

The other (and better way) is to initialize the embed with an HMAC generated on your backend using the API Secret. You can do this with both email and external_id - https://developer.magicbell.io/docs/turn-on-hmac-authenticat....

Hello! Great product and congrats on the launch!

I wanted to pile on a little bit here and say this paragraph isn't really comforting to me:

> While unlikely to happen, it is possible for a savvy user to open their browser's developer console, obtain your MagicBell project's API key from your website's source, initialize the widget on their own website with your API key but with a different user's email (if its feasible for them to guess one) and start viewing notifications of that user.

I suspect this was done for developer experience reasons? You seem to know it's not secure to pass in an email directly, especially if anything sensitive is coming across in notifications.

For me at least, allowing the non-HMAC configuration makes me wonder what other security corners have been cut. I'd rather that option didn't exist and the company took a more security-forward stance.

I agree that this can be worded better and we will certainly do so. Thank you for your feedback. It's fairly common to see this pattern of HMAC off by default (ex: Intercom) to help people test their embed. Atleast at the moment we are in touch with everyone going live and make sure this is communicated to them (doing things that don't scale).

Edited the doc to remove the bit about this scenario being unlikely. We take security very seriously and would be happy to get feedback on the new copy (or any other aspect of MagicBell).

I see your point with Intercom, but it feels like you're arguing that two wrongs make a right. It doesn't make me think MagicBell takes security very seriously, but perhaps I'm just paranoid.

Regardless, the copy on the website is improved. You may also want to add a warning and link anywhere your website documents the "userEmail" option.

On another note, in terms of the implementation here, I'm surprised you're asking users to use HMAC and base64 manually, instead of using standardized JWTs. Did anything in particular motivate that decision?

I quite like the product overall - I think it's very clever how you componentized everything. The security decisions just have me concerned.

Hi thrwaway2020aug, indeed we could have made a better choice in that regard. Actually we plan to move to JWT in the coming months.

Be asured that we take security very seriously. We are in conversations with banking platforms, and with that in view, we are planning to get a SOC 2 certification very soon.

Kudos for starting up.. These kind of features exist today in many martech systems. Full disclosure: I am the founder of one : www.appice.io but we are certainly not the first or only ones.

What sets you apart?

You are right that there are many marketing automation systems for sending emails or push notifications. We are focused on product notifications specific to a user's workflow. The API reflects that and, so does the design of the inbox. For example, the API accepts a category for each notification and you can set preferences per category (one of the categories can be marketing). When adding MagicBell to your frontend, you can write a custom click handler and redirect your user to the specific action they need to take on a notification. A lot of the marketing automation tools also lack an in-app inbox that offers a workflow for these notifications (read/unread/delete).

Is this a NCaaS - a notification-center as a service? That sounds similar to offerings like Pusher, that help you build one of the most complex parts of your app.

Whether this is useful will depend on how flexible the system is. Is it possible to define categories of notifications with different behaviors? Can you customize the UI to fit in seamlessly with your app? When notifications get sent by email, can you send them in batches so the users don't get inundated in task assignments etc?

We are similar to Pusher because we handle real-time updates for you. However, unlike Pusher, we offer UI components to craft a great user experience. You can use the packaged embeddable inbox or use smaller components to build something more custom. The UI is completely customizable to match your brand.

We don't batch emails yet, but we will work on that in the coming months—also, an ability to send digests. The unique thing about our approach (or vision, if I may) is that we want the user to decide how they want to be notified and as an app developer, you shouldn't have to think about it at all.

You can add a category to every notification you send to us, and you can also set up notification preferences for the user based on the category and the channel. In the coming month, you'll be able to add templates based on category and selectively disable channels for some categories. Happy to keep you posted on the development of the product if you leave your email in Intercom. Thanks!

Hi Hana & Josue!

Congratulations on the launch. Love this idea and execution. I have spent too much of my developer life building notification systems. It's a no-brainer to use this.

Congrats on the launch. Just signed up today, and awesome support from Hana and Josue. Looking forward to integrating this in our product.

I was excited when I saw your post, because I have a couple companies that could use this service.

But then I was confused when I saw React.

I'm not sure why you would have developed this in a UI framework like react instead of something more generic and embeddable like vanilla js, or web components?

Hi claytongulick! Very glad to hear about your excitment.

We built a react library for our current customers, and we are planning wrappers for other UI frameworks, too. The core of the MagicBell client, though, is completely decoupled from React.

We also offer a UMD bundle you can embed without having to worry about React at all, and a ESM bundle. Our customers were able to embed it in products with very different stacks.

Sign up and try it! We'll be very happy to help you integrate MagicBell into your product.

We most likely will.

Can you sign a BAA?

I can't tell you how many times we've had to rebuild this feature in the past! Super cool!

Congrats on the launch!

I like the idea of bringing subsystems into fully separated products. First comment boxes and now notifications.

Believe it or not, I was drafting this exact idea this in my notes for the last couple of weeks, haha.

Only concern is having React also be part of the notification integration

Can you please elaborate on this point? What would you prefer instead?

I must clarify that we use preact and not react.

Hi Hana & Josue - congrats on the launch! This looks like a wonderful product. As a developer I've built (admittedly terrible) versions of this, over and over... look forward to trying it!

The hamburger menu on your website doesn't have a close function? Just go to another page

Thanks for pointing this out. We'll fix this shortly.

Congratz on launching !!! Very cool you have Ruby gems.. gonna try it

This looks good, very glad to see MagicBell, push notification systems are extremely hard, just have a look at how Slack manages it and it's just the beginning.

Sometimes they come late, get duplicated or even not arrive at all, i'm excited that there are more startups and companies providing this service.

There are companies out there that provide time critical notification updates, courier systems, parcel tracking, financial services, stock trading, emergency services, cryptocurrency movements, etc that would benefit from this.

I would love to see if there are more startups or products out there like MagicBell that have well designed notification systems that guarantee notification delivery without error.

Kudos on the release!

Update! We love this idea here at Courier (https://www.courier.com/) and just launched a MagicBell integration (https://docs.courier.com/docs/magicbell) to make it easy to send notifications to email via SendGrid/SES/Mailgun/etc., SMS via Twilio/MessageBird/Plivo/etc., mobile push, Slack, MS Teams, and – now – in-app!

Looking forward to finding other cool ways to work together.

Thanks Troy! Love the integration. Quick feedback: We also accept an external_id apart from email. This is the ID of the user in our customers' database. Can you please add support for that?

Sorry we missed that! Will get it added ASAP.

Edit: Docs are updated and change is deploying now. Thanks for the heads up Hana!

Hey Hana – I love what you're doing with in-app. Congrats on YC!

Courier (https://www.courier.com) is also in this space, but we're focused on other channels like email, Slack, SMS, MS Teams, SMS, etc. as well as handling orchestration capabilities around lists, preferences, and sequences. I'm pretty confident you & I started Magicbell & Courier for the same reason: we were both tired of seeing this have to be built over and over.

Glad to see the space is heating up!

Thanks for dropping by Troy! Like you mentioned, we are very focused on the in-app piece as being the gateway to other features (notification preference, asking for permission to push). We believe that our customers shouldn't have to think about channels and how to orchestrate the notification flow. That's something MagicBell should figure out for them.

I am super impressed by your execution and hope to catch up in person once this pandemic is over. It is indeed great to see good solution in this space :)

We use Courier ourselves and LOVE your product

+1 for Courier! Big fan.

+1. Using Courier at Stable (https://www.useStable.com) as well + it's saved us a ton of dev time!

+1, we are happy customers of Courier at LaunchDarkly!

We're just integrating with Courier now!

Big fans of Courier. We use it at Calixa(https://calixa.io) to power our email and Slack notifications to customers. My eng team found it super easy to integrate.

We are just thinking about adding in-app notifications so will have to check out MagicBell. Looks cool. Congrats on launch.

I built this for Airbnb and Courier is creating exactly what we had to have dozens of engineers building for us full-time over a span of 7 years. We are still building it and maintaining it today, but if Courier was around earlier in the days of Airbnb, we would've just used Courier instead of build it in-house and maintain it ourselves.

+1 for Courier!

Were also using Courier at laserfocus (https://laserfocus.io) for e-mail and it has been fantastic so far.

+1 for courier! we at Glimpse (https://www.joinglimpse.com) needed a few new endpoints/features, and the team jumped on to help us launch quickly. great product and even better team behind it.

Great to see more startups in this space. Courier are awesome! And congrats to MagicBell, looking forward to trying it out

we've been using courier since early last year and thank god because otherwise we would have spent 75% of the year building like 25% of courier so that we could email our users. one of the first products that I recommend to any software startup, insane how much time they will save you

> I would love to see if there are more startups or products out there like MagicBell

We don't currently do in-app notifications so not directly like MagicBell, but handle a lot of the other challenges you mentioned. We were heavily inspired by how Slack solves this problem (they're one of our investors):

https://www.courier.com/

Would you please stop hijacking the other startup's launch thread? You've been all over this thread, changing the subject to yourself, and it's in poor taste. Worse, the comments underneath https://news.ycombinator.com/item?id=26038303 look blatantly gamed. I don't know how all those users showed up to talk about you, but if you did anything to make that happen, that's not cool.

You're obviously doing great work in your own right and we'd be happy to help you out on your own thread, but what you're doing in this one is just not very nice. If someone else did that to you, we'd tell them to stop as well.

We detached this subthread from https://news.ycombinator.com/item?id=26040402.

Got it dang. Understood.

Appreciated!

Launch HN: MagicBell (YC W21) – embedded notification system for your product