When Pipes died I saw all the comments and wondered why no one built a successor project. When after a few years that still hadn't happened, and after an idea o

When Pipes died I saw all the comments and wondered why no one built a successor project. When after a few years that still hadn't happened, and after an idea on how to get it to work had popped into my head, I built it myself: https://github.com/pipes-digital/pipes https://github.com/pipes-digital/pipes is the source code and https://www.pipes.digital/ https://www.pipes.digital/ a hosted version. To call it a successor project is maybe arrogant and misleading - it can not do half of what the Yahoo project did, and is sorely missing time and work from my side to make it into what it should be. But if you are nostalgic for the concept and especially if you just want to filter or combine a few RSS feeds, or create one for a HTML page that is missing one, it's worth a try I still think. I personally use it regularly to get specific YouTube videos from a few channels that have many other videos I do not care about. The article mentions one of the big problems for this kind of project: The APIs are missing or not open anymore. For example, a comment here mentions doing a google search for a song title and putting this in a feed - but you can't realistically parse Google. So you have to use the API, which I didn't know existed until looking it up now, and calculate the price tag attached to it very carefully. Maybe it would be a realistic integration to provide with a different search engine. Or a bigger project should run of the local search engines for the pipes block. The article is also right in that there is a lot of influence of Pipes in different projects. I was always wondering why that influence was often so little - to react to output on a page in a wizard for example, instead of having blocks. I think I understand that a little bit better now - it is really a strange abstraction level. You are working with a flow of structured data, without necessarily having the correct data structure for that, and then that needs to be transformed somehow. The idea that you might have JSON on a page somewhere you want to extract and manipulate, but then that data is inside of your outer feed format - it feels wrong to confront the user with these details, it makes sure the target groups is developers, but it also does not seem like something that can be reasonably universally solved. But maybe I'm wrong here, and this is more a problem with my implementation (where RSS is piped from block to block) than with the concept itself. The idea of a real Pipes 2 is very exciting to me though. Give it some initial funding, built all of the modern APIs into it that can be added (and in doubt just give users the option to use their own API keys) - especially things like ChatGPT, after all those LLMs are great in converting structured data - solve the data format question and crucially keep the interface block based (but maybe built with something like Flutter, so it can be better). Could work, not to win the world, but as something that can justify its existence next to ifttt and zapier. At least I regularly get the impression that the concept still fascinates people a lot, though their specific use case is very often very specialized and then often enough not something my small pipes project can cover. But if it were broader...