Times are tough, and we’re facing some big decisions, and we don’t know if $Hive has hit bottom yet. But I hope everything will turn out okay.

Todo va salir bien ya verás no es solo hive ..btc ha bajado mucho

Thank you for the support. These are difficult tradeoffs, but we think it is better to be transparent now and adjust responsibly.

Realistically, this is a tough time for all projects. Ecency’s decision to adjust its costs and commitments transparently is a responsible step. Personally, I appreciate this action by Ecency, and I hope all frontends will take this into consideration.

Tough times but @ecency is tougher 💪. We can be tougher together as a community. Great times are coming and we'll just keep going !BBH !PIZZA

PIZZA!

$PIZZA slices delivered:
@day1001(2/10) tipped @ecency

Send $PIZZA tips in Discord via tip.cc!

Nice

>That may be what the community wants.

I am afraid that is the part of my post some people did not get, or struggle to see clearly. We will not have a coice if we keep deathspiraling.

At this point the only way to show strength is to brace for the impact of bankruptcy. Crypto users are not stupid. They see HIVE reaching all time lows after all time lows, they see HBD losing its peg and they see 6 figure projects financed by a blockchain that is spiralling downwards, who will invest in such a thing? A madman like me but that is not enough.

The community does not want Ecency and other projects to be a hobby, naturally everyone really wants Hive to be a big, professional and profitable blockchain. The harsh financial reality is that it is not possible. We do not have the money. We are broke. We are a few more all time lows from a liquidity collapse.

You probably can see it yourself, you lowered Ecency's ask in HBD, and now HBD is not 1:1 to the USD, so if you lowered it from 333 to 250 HBD that is a 25% reduction, but the HBD is not 1 USD anymore, it is around 80% of the peg, so now instead of 75% the market forced you to have 60% of the original ask.

It is already happening in front of our very eyes. If we keep going down this path you will have 40%, 20%, 10%.... And eventually nothing. That is what I mean. We will not have a choice. And I am hypocritical, I am supporting your proposal when I know it shows we are fragile, it shows we rely on liquidity and it shows we do not have enough hobbyists to support this chain.

We either brace for impact and scale down to a hobby now, willingly, while we can still make mistakes and adjust course, or we scale down later because there is no more money, no liquidity and no time to adjust anything.

It is a sad position, no one asked to be here and most definitely no one wants to be in this position, we want to get out of this position. But we have a choice right now and that matters, if we keep delaying we will not have a choice. The trend is clear. To revert it must adapt to it and prove we can survive even in the worst moment in the history of this blockchain.

>If the community wants reliable open-source frontends

We want but we can't afford. I mean we can now, there is very little liquidity left. But give it a few months, heck, luckily a couple of years, and no, we won't have a choice and everything will be defunded not by the community but by market conditions.

It absolutely sucks, it absolutely pains me, but it has to be said and can't be denied because the trend is clear.

>If the community does not see enough value in that

It is extremely valuable, I support your proposal. But valuing doesn't pay bills.

I am so very sorry, the community values, but it does not value it at 100k+ USD a year, to test this thesis you can ask for donations to keep things running. If you reach 100k+ USD then the community values it. If not it means the community values as 100k+ HBD (which is worth 80% of the face value due to the peg loss) because that feels like a chest of money while in reality it is a portion of the little liquidity we have left, it is not money and it will not pay the bills when we reach a point of total collapse.

We do not disagree with the risk you are pointing at.

Reducing to 250 HBD/day is not a full solution. It is a first adjustment toward the current market reality. If liquidity and support keep weakening, then yes, we will have to scale down further.

The goal is to make that scaling intentional instead of chaotic: keep the most critical infrastructure alive, reduce what can be reduced, and keep pushing revenue paths outside DHF.

We would rather be honest now than pretend the same operating model can continue unchanged forever.

Excelente información muy completa

Open source doesn't mean "never make revenue". I think it could be so easy to make even at this shit market 5k revenue with ecency. Monetize some parts am it works.

I know that would be a business, maybe you dont want to run one.

But at the end to depend 100% on DAO money forever will not work out. And yes Ecency is one of the better proposals, Hivewatchers is 100x worse, runs for years, protect what exactly? Shit content? Well i only see shit content on hive.

And cost way to much for it.

But the point is all "forever" proposals are waste. The 90k Bailout retroactive pay was also a waste ( special at all time low).

Everyone can build software, at the end 99% becomes useless. 1% can survive and this is the 1% makes money. Everything else is a expensive hobby.

Agree. Open source does not mean "never make revenue" and depending only on DAO funding forever is not healthy.

We already have some revenue from paid onboarding and Points sales, but it is still small, roughly 100-150 EUR/month, which is only a fraction of infrastructure and development cost.

The goal is to grow that with more creative revenue paths: paid services, AI Credits, Points, hive-x402, self-hosted/community instances, and other useful tools. But we want to do it without selling user data, invasive tracking, or compromising user privacy.

So the direction is: reduce the DHF ask now, scale commitments accordingly, and keep moving more cost toward revenue where it makes sense.

@crimsonclad is the exchange whisperer right? Some low hanging fruit is simple banners of exchanges on people that not logged in. So people from outside ( google and co) see this. And ofc other affiliate + paid spaces. Thats super simple ( non targeted) revenue stream.

And if you want to build something unique, build a decentralized facebook like advertisement interface. OFC thats a lot of work, but this makes also real money ( beyond hive, people sign up with their website and get paid tracked encrypted on Blockchain).

Every semi big website had to deal with a scam referral program and vise versa. This solves a real problem, reaches beyond hive to monetize websites ( without reward pool) and makes on hive websites also revenue.

This would be worth funding with large $ if the research and architecture is smart. And if something should get funded, it should pay X% back to DAO ( I think all projects should offer a return in some way).

The problem is, DAO for outsiders feels like communism in some way to reward friends of the leadership and even a 1M vote does nothing.

Advertisement is the way to go ( also for Hive projects like the AI credits).

And well the AI credits can fail fast too, if demand is not there and people offer hardware nobody pays. This needs again marketing.

The idea of launch a product and people will find it is retarded and was NEVER true.

Btw in context to other comment i am to lazy to edit. Imagine Hive would have a natural demand to "burn" or "buyback" around 10k USD a month, that would be a good start.

And Hive needs in a long run a way to monetize RC / Blockspace. Retards on Hive fight "low quality content". Well since is objective, they fight users ( i dont talk about obvious scams and spam, even if this is the reaction from the curation ppl).

Non editable AI communication could be huge ( but should be rewarded IMO since this would make it unique).

Github like Code but onchain.

And so on. But at the end as long the space is worthless and highly moderated, is like using reddit without users.

it might be open source but the servers it runs on often require monthly payment to keep them running.

Open source software might look easy from the outside, but keeping servers running always needs money and the developers effort.

Creo que debemos sacarnos las caretas y dejar de fingir que las cosas funcionan cuando no funcionan.

El DHF debería ser un fondo para proyectos nuevos, que necesitan fondos para empezar.

Creo que tanto @ecency como otros proyectos maduros deben empezar a ser auto sustentables. Ya como testigos obtienense ingresos, como receptores de delegaciones obtienen ingresos, ahora falta que empiecen a dar un valor agregado a la comunidad. Si hoy deja de existir ecency, hay como 10 opciones diferentes que lo sustituyen, algunas que ni siquiera reciben fondos.

Creen una base de nuevos usuarios, hagan retención de los mismos, eviten que sus curadores invitados abusen del sistema de recompensas para que sea justo para todos los usuarios, y si necesitan aplicar una tarifa como lo hace 3Speak, háganlo. Si necesitan incluir publicidad, háganlo.

Pero ya dejen de ver al DHF como una mina de Oro que deben explotar. Pronto no habrán usuarios reales que quieran invertir dinero o tiempo, porque el DHF extingue cualquier posible beneficio para inversionistas.

Los únicos que ganan son los "proyectos" financiados y los que deciden en qué fiestas gastar los fondos como @guiltyparties y su amiga que acaba de recibir 90 mil dólares por labores voluntarias pasadas en las cuales disfrutó de beneficios que ningún otro usuario se Hive disfrutó, ni disfruta.

Van a llevar a cero el precio del token.

Por último, publiquen sus balances de pérdidas y ganancias y los documentos respaldatorios. En especial lo relacionado a nómina de personal.

Buenos días, honestamente me parece que siendo programadores tienen una visión limitada de negocios. Su formación es bastante cara en países del primer mundo, pero tiene un defecto fatídico y es que es hiperespecilizada. Y eso les da una ventaja sobre una materia cuando las condiciones son favorables, pero los genera problemas cuando las condiciones iniciales cambian. Es por ello, que podrían considerar otras tres opciones distintas que no han mencionado y que a mí me parecen podrían ayudarles a largo plazo, uno es lanzar una campaña de recaudación en Geyser, Indiegogo, Patreon, etc, para financiar los gastos de la plataforma a cambio le ofrecerían servicios de consultoría a sus patrocinadores. Otra variante de esta idea, no es exactamente publicidad sino que todos los usuarios que esten interesados puedan ofrecer servicios de consultoría a través de esta plataforma (en áreas académicas, criptomonedas, financieras, etc) incentivando a los nuevos clientes a usar la criptomonedas para pagar o directamente ofrecer un pago en efectivo en dolares o euros, y por usar la plaforma ustedes cobran un porcentaje por cada cliente que pague un servicio de consultoria, algo similar a lo que hace workana. También esta la tercera posibilidad de consultar a la audiencia de que servicios profesionales podrian ofrecerse a través de la plaforma tanto en Ecency como en las distintas comunidades de Hive. También es posible combinar las tres propuestas que he hecho, o reformularlas de acuerdo al presupuesto. Pero al final, igual van a tener que cambiar la plataforma para hacerle más rentable. Eso es todo.

Most of these costs are a choice, not a law of nature, and that's what the whole post talks around.

Images on object storage plus a CDN cost a fraction of self-hosted hosting, R2 and friends have zero egress, managed Postgres and search are cheap and simple. You don't need an in-house fleet of nodes, search, indexing and signing services at full redundancy to run a frontend. You've chosen the expensive architecture and you're asking the DHF to fund the difference. The post even admits cheaper setups exist, then reframes picking the costly one as resilience. That's not resilience, that's a spending decision dressed up as a principle.

Hive IS the resilience. The whole point of Hive is that it is decentralised and absorbs a lot of the costs a normal front-end would have to incur. You admit that you have knowingly made things more expensive and complex, but the reasoning doesn't add up for me. I've been around long enough to remember before the rise of cloud computing providers like AWS. It's so cheap to host and run stuff now, and it's safe and easy to configure to abide to by a heap of regulations and standards out of the box.

The Lithuanian fine is unfortunate but it's a one-off, and one-off legal costs don't justify a recurring daily ask. UGC exposure also comes down to how and where you incorporate and operate. The DHF didn't choose to put Ecency under EU jurisdiction. That's on Ecency, and the answer is to structure smarter to limit it, not to bill Hive for it. Europe is a notoriously legislative heavy continent. When you choose to do business in Europe you know you're going to pay more than incorporation somewhere else.

Nobody's saying Ecency does nothing. It does real work and obviously it costs money. But the real conversation is leaner infrastructure at a smaller number, not 250 a day to keep running everything the most expensive way available.

You guys/gals need to get someone who knows what they're doing to get things setup properly for you. Otherwise what's to say you're not going to get another unexpected fine or problem? Ecency is great, but you can't operate with an open source/zero sum mindset or what happens when a cost comes up you can't pay next time?

Fair pushback. Costs are choices, and we are not rejecting cost reduction.

Thanks for actual suggestions! But the "just move to R2/object storage/CDN" assumption is not automatically cheaper for our actual usage pattern. We did a rough comparison for image infrastructure, and a full migration to that kind of setup looked roughly 2.5x more expensive for us, not cheaper.

R2 has attractive parts, especially egress, but the full cost depends on storage volume, request volume, cache behavior, transformations, migration work, and operational requirements. Managed services can reduce some maintenance, but they do not always reduce total cost.

There are also only a few public imagehoster instances we are aware of, mainly images.hive.blog and images.ecency.com. Ecency apps can already use images.hive.blog, so yes, switching away from our own imagehoster would be one way to reduce cost. But that does not make the cost disappear. It mostly shifts more load and responsibility onto another operator.

The same applies to public RPC infrastructure. api.hive.blog and images.hive.blog are valuable services, but they are not free to run just because users do not see a bill. Someone still pays for servers, bandwidth, maintenance, and operations. Running independent Ecency infrastructure gives Hive a second path, adds redundancy, and reduces the burden on a single generous supporter or operator of the chain.

Where we agree is that architecture should be reviewed and simplified where possible. That is part of why we reduced the ask and said we will scale down commitments.

Where we disagree is that Hive alone covers the frontend layer. Hive stores the chain, but users still need reliable access, images, search/indexing, APIs, onboarding, abuse handling, support, monitoring, and maintained apps.

The code is open source, and if the community believes this can be operated much cheaper with a concrete architecture, we welcome proposals, PRs, or community-run instances. But whoever runs it has to take responsibility for the full operational surface, not only the parts that look simple from outside.

Not to sound combative here, because I love you guys and I don't want to see you fail. I'm just approaching this purely from a non-biased perspective. Are you comfortable sharing the costs for infrastructure? Because I think you'd find collectively there are enough tech-minded people here who would gladly help you optimise your setup if there is room for improvement. Or make recommendations to improve things.

Really, the 2.5x is the part I'd want broken down though, because with zero egress on R2 the cost can't be bandwidth, so it's coming from somewhere else, and your own list points right at it: transformations. If you're doing on the fly resizing and optimisation, that's almost certainly the driver, not storage.

If that's the case, the cheaper pattern isn't R2 instead of your hoster, it's R2 for storage plus a transform layer that caches variants. Generate each size once, push it to CDN cache, never reprocess it. imgproxy or thumbor on a small box, or even Workers, in front of R2, with aggressive cache headers. Then transforms are a one-time cost per variant instead of per request, and egress stays zero. A naive setup that reprocesses or caches poorly absolutely can come out 2.5x, so I believe your number. I just don't think it's measuring the cheap version.

If financial figures are too much, usage numbers would suffice: rough storage volume, monthly request count, egress GB, cache hit rate, transform volume. With those we can get a clearer picture of the scale.

The redundancy point I'll give you. That's the real argument and it's a good one, especially for RPC. A second independent path matters and someone does pay for api.hive.blog. The only caveat is that a DHF-funded operator being the redundancy is its own kind of dependency, so for images specifically I'd still rather see mirrored, replaceable hosting than one funded host, even if that host is you.

I think this highlights that Hive has a serious problem on a core level. If we're relying on ecosystem apps to ask for funding to sustain core critical redundancy of the chain outside of the chain itself, I think it's worth flagging that as a serious issue with Hive itself and one that could compromise it down the track if our market cap keeps slipping and HBD's pegged value continues to fall.

I appreciate the constructive tone.

We are comfortable sharing the high-level cost structure and we already publish broader transparency information at https://trust.ecency.com also we have https://status.ecency.com page, not all services/servers there yet but we are moving all there. If there is room to improve the setup, we want people to point it out, as we reach new proposal starting date we will put down latest numbers and changes in spreadsheet. Create transparency report/post as before.

On the 2.5x number: you are right that zero egress on R2 is not the whole story. And our estimation was based on cloudflare's documentation compared with our own usage, storage, transfers, etc. It was not meant to claim that R2 is inherently more expensive in every possible setup.

On redundancy, I agree with you. A second independent path matters, especially for RPC and image access. The point is that the dependency does not disappear, it just moves somewhere else.

So yes, we welcome concrete optimization ideas or a deeper architecture review if people want to help.

Me gustó mucho eso de "Source Costless: Scaling", @ecency. Buen contenido!