dittofeed VS hyperdx

Hey HN, we just released Dittofeed v0.13.1! Dittofeed is an open-source, MIT-licensed alternative to customer engagement platforms like Customer.io and Braze. This release introduces several features that really expand how you can use Dittofeed:

- *New Webhook Channel*: This channel lets you make API requests directly from user journeys. It's useful for:

1. Use cases include sending Slack messages, triggering native mobile push notifications.

2. Sending messages with your internal APIs.

3. Integrating messaging channels that Dittofeed doesn't yet support natively.

- *Admin API*: The Admin API allows you to programmatically manage your Dittofeed workspace. This release includes endpoints for managing users, searching user events, and more.

- *Improved Template Publishing UX*: Our template editor now allows you to visually compare your drafts against published templates, simplifying the publication process and ensuring you don’t lose track of your changes.

For a more detailed breakdown of what’s included in v0.13.1, check out our blog post:

https://dittofeed.com/blog/release-0-13-1

And for those self-hosting Dittofeed, make sure to consult our latest upgrade guide:

https://docs.dittofeed.com/deployment/self-hosted/upgrade-guide/v0-13-0

We'd really appreciate it if you visited and starred our repo to help support the project:

https://github.com/dittofeed/dittofeed

Thanks all!

Hey HN, Dittofeed v0.12.1 is out! For those unfamiliar, Dittofeed is an MIT-licensed, open-source platform for omnichannel customer engagement, offering an alternative to tools like Customer.io and Braze. This release focuses on key optimizations and fixes, enhancing performance and compliance:

- New "NotEquals" Segment Operator: Now, you can exclude users based on the absence of specific traits, enabling more precise targeting in your Journeys.

- Optimized Query Memory Efficiency: We've significantly improved the memory efficiency of our computed property engine, powered by ClickHouse. This is helpful for teams self-hosting Dittofeed.

- Subscription Email Headers: We've updated our email headers for subscription-related emails to comply with Bulk email sender guidelines, improving deliverability.

- Improved Messaging Stats: Addressed an edge case with Sendgrid webhook events that could lead to inaccurate messaging stats.

For a detailed look at the contents of v0.12.1 you can read our blog post.

https://dittofeed.com/blog/release-0-12-1

For self-hosting users, see our upgrade guide:

https://docs.dittofeed.com/deployment/self-hosted/upgrade-guide/v0-12-0

We’d really appreciate it if you visited and starred our repo.

https://github.com/dittofeed/dittofeed

Thanks!

- You can now send test messages to yourself to ensure proper rendering in different email clients, validate ESP credentials, etc.

Release blog post with all updates [here](https://dittofeed.com/blog/release-0-6-0). Hope to hear your thoughts!

Github Repo - https://github.com/dittofeed/dittofeed

Demo - https://demo.dittofeed.com/dashboard/journeys

Docs - https://docs.dittofeed.com/getting-started

Polytomic Docs - https://docs.polytomic.com/docs/getting-started

Dittofeed Polytomic Docs - https://docs.dittofeed.com/integrations/sources/polytomic

Hey HN, we’ve just released Dittofeed v0.5.0, with the primary change being the addition of SMS as a messaging channel. Dittofeed is an open source (MIT licensed) omnichannel customer engagement platform, similar to Customer.io and Iterable. We added:

- Twilio-based SMS messaging. You can create SMS templates and customer journeys within Dittofeed.

SMS is a great channel for B2C software companies, looking to engage with their users. For example, e-commerce businesses commonly use SMS to support checkout flows.

We'll be making further enhancements to Dittofeed's SMS support in the coming weeks!

- We added a new "Trait Exists" segmentation option, which can be used to create a segment of all users with phone numbers, for example.

- We made some fairly large improvements to our settings UI. Big shout out to our contributor! https://github.com/promisetochi

The full feature release blog post can be found here: https://dittofeed.com/blog/release-0-5-0.

Looking forward to your thoughts and feedback!

Github Repo - https://github.com/dittofeed/dittofeed

Demo - https://demo.dittofeed.com/dashboard/journeys

Docs - https://docs.dittofeed.com/getting-started

GitHub Repo: https://github.com/dittofeed/dittofeed

Hi HN - we’re Max and Chandler, and we’re building Dittofeed https://dittofeed.com. We make it easy for growth and marketing teams to message their customers across multiple channels. We're an open source alternative to platforms like Iterable, http://customer.io/, Braze, and OneSignal. Here’s a short demo video showing how to run the platform locally, and use it to automate a customer onboarding journey:

https://www.loom.com/share/0f7b67170b3a4205add00c22844ca06f

We created Dittofeed to tackle some commonly felt pains with customer engagement platforms.

Firstly, existing platforms make it difficult to keep imported user data accurate and up to date with your primary user datastore. To solve this, we’re building first-class support for importing data from your data warehouse, for better data consistency.

Secondly, graphical “journey builders” are fragile, and difficult to debug at scale, so we’re building git-based workflows to check your messaging automation into git as configuration, as well the ability to run Dittofeed locally in development, or in CI with our testing sdk, for improved ease of debugging.

Lastly, companies in industries like finance and healthcare are often forced to implement their own solutions in-house to avoid sharing sensitive PII with third parties. As an open source platform, companies can now self-host us to keep their PII in their network.

Chandler, having worked in marketing for startups, experienced these challenges first hand. Max, on the other hand, was a senior platform infrastructure engineer at Braze, where he witnessed similar challenges from a technical perspective. Our combined experiences sparked the idea for Dittofeed.

We decided to create an open source, developer-focused customer engagement platform, because the often unspoken truth is that maximizing the effectiveness of these tools requires ongoing engineering involvement.

Dittofeed is built on Clickhouse (OLAP store used for storing user events, performing user segmentation, and aggregations) and Postgres (OLTP store for persisting application configuration, and serving user aggregations for efficient single-row reads).

If you can use the following, we’d love it if you checked us out:

Email support via sendgrid (other channels coming soon).

User data import via Segment integration.

We have a cloud offering, and offer paid support. You can find our pricing on our site https://dittofeed.com/pricing.

How to try Dittofeed out:

Check out our demo site to play around with the app https://demo.dittofeed.com/dashboard

Run the app locally via docker compose (https://docs.dittofeed.com/deployment/self-hosted/docker-com...).

Join our slack and we’ll set you up with cloud hosting (https://join.slack.com/t/dittofeed-community/shared_invite/z...)

We’d love to hear your thoughts, opinions, and experiences with these tools. What’s been your experience working with this kind of tech?

Hi HN, Mike and Warren here! We’ve been building an open source local-dev-friendly mode for HyperDX (hyperdx.io). It's a single Docker container that lets you view logs, metrics, and traces for local development in a similar way you can use them for production (live tail, filter/correlate logs & spans, build charts, flamegraph, etc.) Basically, imagine you can run Datadog in a single container for local development. We does this by spinning up an OpenTelemetry collector, Clickhouse DB and HyperDX UI all in a single container - it only takes a few seconds to start and lets you start live tailing your local logs and traces immediately (and graph metrics of course).

README (w/ demo gif): https://github.com/hyperdxio/hyperdx/blob/main/LOCAL.md

We started building local mode as it became one of our most loved [1] community issue after sharing HyperDX. It made sense - as we constantly use HyperDX to debug our own issues locally, and have found it to be a huge productivity boost for things like…

1. Tailing multiple container logs (and grepping/isolating them) without a ton of different terminal splits open at the same time.

2. Be able to sensibly view structured logs and correlated traces to debug local issues (because you’re using structured logging and tracing right?) instead of adding ad-hoc console statements that print out exactly what I could’ve gotten from tracing.

3. Testing telemetry are actually emitting/correlating as expected, before shipping it all the way out to prod and realizing I accidentally created a very expensive high-cardinality metric or a span that has the wrong properties.

We spent some time packaging & tuning our existing OSS stack to run in a single container with less memory/space requirements by staring at `dive` to slim down the image and applied incantations from documentation until memory usage improved. Additionally we removed a few non-local-friendly things like authentication requirements and extraneous services.

It still has all the goodness you’d want - so you can full text search your logs/traces, live tail all your events, view spans correlated with logs (and vice versa), create dashboards based on logs, metrics, traces, and is fully OpenTelemetry compatible - just point your Otel SDK/collector to http://localhost:4318 (or 4317 for the grpc folks) and you’re already good to go.

I’m excited to share what we’ve been working on and would love to hear your feedback and opinions!

Spin up the container yourself to try it out:

docker run -p 8000:8000 -p 4318:4318 -p 4317:4317 -p 8080:8080 -p 8002:8002 hyperdx/hyperdx-local

Main Open Source Repo: https://github.com/hyperdxio/hyperdx

Hosted Demo (in case you want to play around in a cloud sandbox instead): https://api.hyperdx.io/login/demo

HyperDX Landing Page: https://hyperdx.io

[1]: https://github.com/hyperdxio/hyperdx/issues/7

ClickHouse also excels at storing and querying semi-structured data, like event logs. Previously, many engineering teams used Elasticsearch in a similar niche to ClickHouse, building applications like Kibana. Increasingly, developers are choosing ClickHouse over Elasticsearch for its unparalleled performance characteristics. For example, our friends at hyperdx.io are using ClickHouse to build an open-source OpenTelemetry provider!

HyperDX

Biased as a founder in the space [1] but I think with OpenTelemetry + OSS extensible observability tooling, the holy grail of one tool is more realizable than ever.

Vendor lock in with Otel now is hopefully a thing of the past - but now that more obs solutions are going open source, hopefully it's not necessarily true that one tool would be mediocre over all use cases (since DD and the likes are inherently limited by their own engineering teams, vs OSS products can have community/customer contributions to improve the surface area over time on top of the core maintainer's work).

[1] https://github.com/hyperdxio/hyperdx

HyperDX (YC S22) | Founding Engineer | SF Bay Area HQ | REMOTE

We're building an open source, dev friendly observability tool (think Datadog, but something developers actually love to use and companies can actually afford).

We're in the intersection of needing to build rock solid infrastructure ingesting TBs of data, searching it incredibly quickly and scalably, and layering on top a buttery smooth DX from our language-specific SDKs, APIs and web app.

We're super early and hiring our first founding engineer. We already have a cloud product customers pay for and love, loads of runway regardless of the wider economy, 5k+ Github stars weeks after our OSS launch, and tons of hard technical problems.

The vast majority of our work is open source, so you can get a sense of what you'd be working with here: https://github.com/hyperdxio/hyperdx

Our job listing is here as well: https://www.ycombinator.com/companies/hyperdx/jobs/zFXTbzl-f...

Come by our discord as well if you just want to talk shop: https://discord.gg/FErRRKU78j

I'm Mike, one of the cofounders. If you love shipping quickly and want to help us build from the ground up an open source developer tool (that devs won't hate when they're on-call), let me know! mike [at] hyperdx.io

Oh huh! What would you do with span start independent of stops?

A tangent on logcat - local observability to me is a really intriguing area, I think there's a story of Otel for local as well if someone can build a good enough local DX for consuming them (we've been told a number of times about this https://github.com/hyperdxio/hyperdx/issues/7 as an example)

Hi HN, Mike and Warren here! We’ve been building HyperDX (hyperdx.io). HyperDX allows you to easily search and correlate logs, traces, metrics (alpha), and session replays all in one place. For example, if a user reports a bug “this button doesn’t work," an engineer can play back what the user was doing in their browser and trace API calls back to the backend logs for that specific request, all from a single view. Github Repo: https://github.com/hyperdxio/hyperdx

We're building the OSS equivalent when it comes to the observability side of Splunk/DD, on Clickhouse naturally of course but believe in the same end goal of lowering cost via separation of compute and storage.

https://github.com/hyperdxio/hyperdx