mcharawi

anyone have an archive link for this?

I used https://www.flow.club/ which i found very helpful, they do small groups rather than one on one, and you can sign up ahead of time or join spontaneously

This article didn't really say all too much, essentialy you can't differentiate your product with prompts alone, and you need deeper integrations with workflows, ok thats pretty clear - what else?

Changed the title only because i want to highlight the live stream of the flight today!

I'm also skeptical of people talking on behalf of others in situations like this. I'd like to hear what the migrant workers think

No congratulations is necessary the Laudspeaker project (https://github.com/laudspeaker/laudspeaker) is doing perfectly fine.

$75/mo is not particularly expensive, Braze's starter plan is close to $35k/year

Hey, happy to clear up the confusion! The software is similar to a CRM in that we message users/customers, though we don’t track things like the stage of a sales deal.

Our software and competitors like Braze are typically used in situations where you can’t have a personal connection, but still need to message users, often when they complete specific actions in your application, or if you want to send one-off promotions for example. E-commerce brands or a banking app might use us for example.

We do support replacement variables like you mentioned and are adding integrations actively.

If you're interested in an enterprise plan, we help you set up and scale self-hosting as part of the support contract for as long as you need. We have one-click infra-as-code to get you set up on multiple cloud providers with minimal devops intervention.

If you want to self host for free, the easiest way would be to run our docker compose on a compute instance-we're in the process of updating our docs for self hosting and I can email you with more info if you'd like.

We have support for twilio natively since that's one of the popular options, but we also support webhooks as a channel, so if your Asterisk server has an HTTP endpoint that can trigger messages it would be compatible.

It was fun writing this article, not only because it reminded me of problem sets from college, but also to see the potential of no-code tools to be just as powerful as a conventional programming language. Proving another tool, like Zapier for example, can simulate a finite automata, can be left an exercise for the reader.

I suspect some are much closer to simulating Turing machines than others. In theory, no automata can simulate a Turing machine unless it has access to unbounded (infinite) memory, which can't actually happen in the real world. If there's branching, for loops, and some proxy for memory like reusable registers, it can certainly approach a Turing machine. So maybe Zapier is? I don't recall many tools having a proxy for reusable memory though.

Hey, cofounder of laudspeaker here. If you want to try it out, you can deploy to render without having to really do any heavy lifting. We are just getting started with respect to the business model so we’re open to feedback on pricing. Email me at mahamad at laudspeaker dot com and we can chat!

Hey, cofounder of Laudspeaker here. At a high level, there are two main problems to solve for when it comes to scaling this type of system. One is the ability of your infrastructure to handle resource intensive customer requests (sending 10 million emails) that are instantiated at arbitrary unpredictable times—this sort of work is usually best handled using job queues and job processing threads that are horizontally scalable. The second is the channel specific failure modes that are common at higher message sending volumes, for example IP blacklisting by spam filters for email, or sending the same notifications repeatedly when dealing with mobile push. We’ve set up our architecture to tackle the first problem and are currently performing stress testing to find and fix any bottlenecks there; with respect to the second type of problem, we are actively experimenting with ways to mitigate these failure modes as our product matures.

thanks!

A couple of reasons, first of all we're passionate about open source and we've been seeing the rise of an open source SaaS ecosystem, companies like PostHog, Mattermost etc. We think the more companies here the better, there is a lower chance of vendor lock in, data transfer costs etc if you use an open source solution, and marketing automation software is no different. Secondly and we alluded to this, an omnichannel messaging platform needs a lot of channels, and integrations to be useful to the market, and it makes sense for other contributers to be able to add customize as needed - we are looking into how to make this easier for people to do. Thirdly customer messaging and marketing automation in general is getting more complex, and often touches developers at larger companies, we think most of the solutions out there today don't treat them as first class customers - we are looking to make their experience better as well. We have a few features in the works, like complex journey testing (where you can simulate events, time travel, etc) and wanted to make the self hosting aspect easy as well.

Do you think the 'professionals' were exploited?

Hey, thanks for your comment-you're right there aren't too many details on the protocol changes we made in part because we will follow up on that in another post. This blog post was getting too long as it is and we wanted to focus more on the need to simulate and test. Your comments on the hacker news post you link too actually partially served to inspire us!

At the moment we offer both options. We offer our own network with a pricing plan similar to massive.io (though 10c per gb vs 25c) Our licensing is cheaper but requires large volumes.

Thanks for the feedback. The file transfer ecosystem is very large and conducting a through review of the application level tools was not the goal of this project, as the overwhelming majority of them focus on differences at the application layer, not the transport layer.

We are specifically focusing on rebuilding a congestion control algorithm from the ground up that can better tolerate modern network conditions, including things like high bandwidth, high packet loss, and high latency.

With respect to Grid-FTP, wget2 multi-threading, and other multi-flow approaches: the problem with getting performance increases out of multiple, distinct traffic flows is that you become more and more unfair to other packet traffic as you increase the number of flows you are using. For example, if you use 9 TCP (or any other AIMD) flows to send a file over some link, and a tenth connection is started, you now are taking up to 90% of the available bandwidth (because AIMD flows are designed to be fair amongst themselves).

So congestion and packet loss are different problems; it is true that forward error correction could be a good way to avoid retransmitting lost packets, but the only way to avoid congestion is to adjust the congestion window (for window based congestion control) or packet sending rate (for rate based congestion control) based on some indicator of congestion.

The canonical UDT implementation does not come with encryption, however there are some older open source GitHub repos that have attempted to add TLS to UDT. The original author of UDT, Yunhong Gu, has a project called Sector/Sphere that adds some application-level encryption to file transfer if you want to check it out: http://sector.sourceforge.net/. We've added encryption for our algorithm though!

With respect to QUIC, I believe it was designed specifically to reduce the latency of HTTP connections by using multiple UDP flows and building the reliability/ordering guarantees at the application layer.

The problem with getting performance increases out of multiple, distinct traffic flows is that you become more and more unfair to other packet traffic as you increase the number of flows you are using. For example, if you use 9 TCP (or any other AIMD) flows to send a file over some link, and a tenth connection is started, you now are taking up to 90% of the available bandwidth (because AIMD flows are designed to be fair amongst themselves).

Thanks for reading!

I haven't seen hpn-ssh before, but from a cursory look at the project page it looks like the main improvements are targeted at improving the speed of the encryption using multi-threading, and increasing ssh/scp buffer sizes. These are certainly good improvements over standard ssh/scp (and setting TCP buffers to the value of the bandwidth delay product for a particular network path is a well known way to squeeze some perf out of TCP) but do not address the root cause of slowdown in window-based, loss-based congestion control.

In order to be fair to other flows, exponential back-off is required on detection of congestion, and packet loss as an indicator of congestion is both a lagging indicator of congestion and has a very low signal to noise ratio on high throughput, lossy networks.

Thanks for taking the time to read it! To address your concerns:

1. To give you an idea of the speed improvements, we transferred a 2GB file between Ohio and Singapore on AWS and were able to transfer it in 0:26 (seconds) using our protocol, vs 2:15 for SCP.

2. The basis for improvement is taking into account the changes in round-trip-time for a particular network path; these temporary increases are used as the primary congestion signal.

We are not using error correcting codes, which are good for preventing the retransmission of packets but do not address the underlying problem of avoiding congestion in a network.

Thanks for the feedback-we're actually planning to open-source a version of our work that significantly improves on the original UDT project: https://udt.sourceforge.io/.

Sorry about the typo-you are right it should be Gbps. As for the transfer time, we are just using bits for the file size to make the mental math easier.

Standard SSH uses TCP over port 22 by default, so it wouldn't be possible without modifying SSH to use a different protocol. That being said, however, our protocol uses TLS over UDP via the OpenSSL libraries so it is secure by default. We also offer a BSD-style socket interface that you can use if you want a drop in replacement for TCP sockets. Shoot me a note at mahamad _at_ trytachyon _dot_ com if you want to chat!

Hey HN! I'm Mahamad, co-founder of Tachyon Transfer, where we're building faster file transfer tools for developers. We've spent the last year building an ultra-fast FTP replacement, and we thought we'd show you guys what our technical process was like. Let me know if you have any questions!