Hello everyone!
I have had the pleasure of working on Hive for six incredible years, and I am grateful for the support you have all given me. I would like to carry on working as a core developer and contributing to Hive for a seventh year.
Who am I
I have been on this chain for more than 9 years now.
I went from regular blogging, to contributing to open source on Hive, to building dapps and running a top 20 witness (@steempress, now deprecated). And now I sit at rank 21 with my renewed witness (@howo). I became much more involved in core development when we forked away from Steem, rising to the occasion as we needed every hand we could get to birth the chain. I contributed to the soft fork that locked Justin Sun's funds and later to the very first hard fork that created Hive. Ever since, I've been working as a core developer contributing to Hive and Hivemind, implementing sensible requests from the community and hosting core dev meetings where every month, core contributors to the ecosystem get together and collaborate on ideas and share what they are doing.
If you're interested in my full journey, I made a throwback post retracing most of my activities on Steem and then Hive here a while ago: https://peakd.com/hive/@howo/my-hive-story
My work
Over the years I've shipped a number of features you may be familiar with: recurrent transfers, RC delegations, the Mesh API (coinbase integration), to name a few. Rather than revisiting those at length, I'd like to focus on what I've been building more recently.
Hard Fork 28
HF28 shipped a few months ago and included a bunch of my features:
Multiple recurrent transfers for the same sender/receiver pair: Previously, you could only have a single active recurrent transfer between any two accounts. This was a meaningful limitation for builders — imagine wanting to run both a subscription payment and a separate payment stream to the same account. HF28 lifts that restriction entirely, allowing any number of concurrent recurrent transfers. This is what peakd leverages for their open market feature
Removing DHF HBD from inflation calculations: This one is directly relevant to the current inflation debate (more on that later). Before this change, there was a risk of an uncontrolled inflationary spiral: if the HIVE price dropped far enough, the HBD sitting in the DHF would represent a growing share of market cap, which would increase inflation — which would push the price down further, which would increase inflation, and so on. The only way to prevent this was a proposal to burn DHF funds, but the protocol prevents burning more than 1% of the fund per day — which is far too slow to react to a fast-moving market event (and also forces us to burn pretty much the majority of the DHF funds). This change eliminates that risk entirely. A side effect of it is also that inflation via the reward pool and witness rewards dropped significantly post hard fork.
Community Features
This year has been focused on a lot of in-depth reworks. Thanks to big advancements in agentic coding (AI), many tasks that I've been putting off for years because they would take too long are now possible and being tackled.
For instance I've migrated most of the community code from Python to PgSQL, which led to massive improvements, doubling the speed at which we process those transactions by moving all of that logic into optimized SQL functions that run directly in the database instead of round-tripping through Python.
Another big rework completely changed the way notifications are processed for communities, enabling a lot of UX improvements for users and moderators. You now know when your post gets muted (and why!). When your role or title changes, you get notified. Users can now flag a post for moderators to review if they think it broke the rules.
There's also a bunch of features that are ready to ship but haven't been included in the latest release yet:
In line with the better UX for communities, I've added a complete moderation API to let community owners actually manage their communities properly. You'll be able to pull up any user and see their full history - how many times they've been flagged, muted, what actions were taken and by whom, with full date-based pagination so you can browse through everything. There's also a moderation stats endpoint that gives you an overview of your team's and users' activity. The idea is to give community owners real tools to make informed decisions instead of just guessing whether someone deserves a permanent ban or just a warning.
On the notification side, several users have surfaced the need for the ability to "subscribe" to a post and get notified of every reply. Right now if you make a post and a conversation starts in the comments, you have no way to follow it without manually checking back. With this feature, you'll be able to subscribe to any post or comment and receive a notification for every new reply in that thread. It works as a simple custom_json operation on-chain, so any frontend can integrate it easily. There's a cap of 16 subscriptions per user to keep things reasonable, and unsubscribing is just as straightforward.
For You Feed
Finally, my most recent work tackles one of Hive's biggest usability gaps: content discovery. Right now, finding content you actually care about means manually jumping between communities, trending pages, curator feeds, and reblogs. That was fine in the Myspace era, but it's not how people expect social media to work in 2026.
I'm building a "for you" feed - a single unified feed that pulls posts from all your sources (communities, follows, trending, tags) and ranks them based on your actual behavior. If you start commenting on gardening posts, more gardening shows up. If you interact with a specific author daily, their new posts surface first. If your close mutual connections are all engaging with a post from someone you don't follow, it gets surfaced as a discovery candidate.
Under the hood, every post gets scored on multiple signals: how much you interact with the author, comment velocity, payout quality, freshness, social proof from mutual connections, and community/tag affinity. There are also diversity rules to prevent any single author from dominating and to ensure a healthy mix of followed content and new discoveries.
This is still a work in progress - it's computationally heavy and because we want to stay as decentralized as possible, we can't just throw more hardware at it. But the foundation is there and I'm building it up piece by piece. I'm also exploring extending this to post-level recommendations, think "if you liked this post, check out this one."
If you're interested in the full technical breakdown, I wrote about it here: https://peakd.com/hive/@howo/content-discovery-feeds-and-decentralized-social-media
The small tasks:tm:
Then there's all the smaller stuff that doesn't always make it into changelogs but matters just as much: fixing bugs that users and Dapp developers report, speeding up slow queries, plugging gaps in input validation, keeping the devportal docs accurate and up to date, squashing UI annoyances on Block Explorer and Condenser (dark mode glitches, broken pickers, missing translations), cleaning up old code nobody needs anymore (dead MySQL references, deprecated tables, leftover files), tweaking APIs when Dapp teams ask for something reasonable (extra filter params, cleaner response formats, consistent errors), making tests less flaky. None of it is glamorous, but it's what keeps things running smoothly and saves everyone else headaches down the line.
A word on the current spending debate
There has been a lot of discussion lately about DHF spending, inflation and price, and I want to address it directly rather than pretend it isn't happening.
I am reducing my proposal by approximately 17% — going from 350 to 300 HBD/day. I think some belt-tightening is healthy for the ecosystem, and I want to lead by example rather than just talk about it.
That said, I think it's misguided to focus all the pressure on reducing spending. We are living through a moment where AI is changing the economics of software development.
That can be used in one of two ways: we can go at the same pace for a third of the cost, or we can go ten times faster for the same cost. Every serious competitor in this space is choosing the second option. Beyond the promise of better inflation numbers, I don't see a concrete plan for what Hive does with the savings. I'd much rather see us continue to use all the resources available, move fast, and take a real shot at growing and succeeding than limp along into irrelevance while our developers quietly migrate to other ecosystems.
What's next
In the short term, the priority is getting the features that are already done into production: the moderation API and post subscriptions. These are built, tested, and waiting for a release.
The for-you feed is the big ongoing project and will likely last for a while as I fine-tune it with feedback and monitor performance impacts. The foundation is solid and I'm actively working on it. I'll also be looking into expanding the algorithm for post-level suggestions (think "if you liked this, check this out") to improve content virality and make users want to spend more time on front ends and make our chain more valuable.
Payment infrastructure for HBD
One thing I've been thinking about a lot is how to make HBD actually useful beyond our ecosystem. We have a stablecoin with zero transfer fees, 3-second settlement, and a 14% savings rate. That's a genuinely compelling product. But the infrastructure for actually using HBD for real-world payments and subscriptions doesn't exist at the protocol level. Every project that wants to build on this has to start from scratch.
I want to change that by building the core infrastructure that makes payment-based applications possible on Hive. This isn't about building a product. It's about building the rails that products can run on. Concretely:
A HAF application for subscription and payment state tracking. Right now, if you want to know "does account X have an active recurrent transfer to account Y of at least 5 HBD per month?", you have to scan the chain yourself. I'm building a dedicated HAF app that indexes all recurrent transfer relationships and exposes them through clean APIs. Any frontend or dapp can query subscriber lists, verify access rights, and pull payment analytics without building their own indexer. This is the same kind of infrastructure work I've done with communities: moving complex state tracking into optimized SQL and making it available to everyone.
A standardized payment request protocol. There's currently no standard way for a merchant or creator to say "here's an invoice, pay this amount, here's your receipt." I'll be defining custom_json schemas for payment requests, confirmations, and receipts, the kind of boring-but-essential plumbing that every payment application needs. For transactions that need buyer protection, the standard will integrate with Hive's existing escrow operations, so you get built-in dispute resolution without reinventing the wheel. This builds directly on the recurrent transfer and escrow infrastructure already in the protocol that I've been working towards over the past years.
A content encryption standard for gated content. This is the part I'm most excited about. Hive has all the building blocks for a decentralized Patreon/Substack: recurrent transfers for billing, custom_json for metadata, and memo keys for encryption. The missing piece is a standard way to encrypt premium content so that only paying subscribers can read it. Since everything on Hive is on-chain and public, Hivemind-level gating isn't enough. You need real cryptographic enforcement. I'm designing an encryption scheme that uses our existing memo key infrastructure (ECDH shared secrets) to distribute content decryption keys to subscribers. Monthly key rotation means cancelled subscribers lose access to new content, and the whole thing works without any hard fork. It's custom_json operations, a HAF indexer, and a reference encryption library that frontends can integrate.
The key distribution can be handled by multiple independent delegates. No single service controls access. A delegate is just a process that watches the HAF database for new subscribers and posts wrapped keys. If one goes down, others pick up the slack. It's a similar redundancy model to how we run API nodes today.
Community applications and gated communities. Communities today are fully open: anyone can subscribe and post. There's no concept of "apply to join" where moderators vet users before they get in. I want to add a proper application workflow that opens up an entire category of community types Hive currently can't support. Users submit an application (with community-defined questions), moderators review through the dashboard I already built, and approval either makes them a member outright or activates a recurring membership payment. Communities can be configured as open, application-required, or application-plus-payment-required.
This ties directly into the rest of the payment stack: membership fees are just recurrent transfers in HBD, member-only posts use the same encryption standard as creator subscriptions, and revenue splits across moderators and contributors use the existing beneficiary infrastructure. The result is something genuinely new: professional communities (verified credentials, alumni networks, expert groups), paid niche communities (trading insights, premium hobby groups), and vetted discussion spaces, all natively on Hive with built-in billing and access control. It also fixes the cold-start problem of individual creator subscriptions: a community with 10 contributors and 500 paying members is easier to bootstrap than 10 creators each trying to find 50 subscribers. Most of the infrastructure is already there (community tables, roles, moderation API, notifications, recurrent transfers). What's new is the application workflow, community-level membership gating, and the glue that connects it all.
Why this matters for token demand: every subscription payment, membership fee, and merchant transaction is in HBD. HBD demand means HIVE demand through the conversion mechanism. Creators and community treasuries holding HBD in savings at 14% means supply locked up rather than sold. It's not speculative, it's mechanical. And the infrastructure I'm building is general-purpose: it enables creator subscriptions, paid communities, merchant payments, SaaS billing, or anything else that needs "has this person paid?" logic on-chain.
To be clear about what's in scope and what isn't: I'm building the protocol layer and infrastructure. The consumer-facing product, the pretty frontend, the fiat on-ramp, the creator marketing, that's for Dapps teams. My job is to make sure the rails are there and they work. That being said I will build a demo patreon/substack clone to showcase investors and builders what's possible.
Ongoing work
I'll also be spending time on the reputation system. It's been broken for a while and there are ways to improve it to make it a more relevant metric again. Speaking of reputation, I'll be working on tackling issues around certain users spamming the chain and improving the overall experience for normal users so they can effectively mute them into nonexistence. This has already started with some of my API changes but there is more work to do.
There is also a lot of optimization work waiting to be done, especially now that making large overhauls is so much cheaper. Very much in line with what I've done with communities, there are plenty of opportunities to speed things up significantly.
On top of that, AI has gotten incredibly good at finding vulnerabilities, as we've seen in recent developments. This is both a good and a bad thing: it's now a race to leverage those tools to find and fix vulnerabilities before they are exploited. The Hive ecosystem is no different, and I've already started this work with input validation hardening and XSS fixes on Condenser and HiveD. Expect more of this going forward.
Beyond that, I'll keep doing what I've always done: fixing bugs, responding to feedback from users and Dapp teams, keeping the devportal and docs up to date, and hosting the monthly core dev meetings. The work is rarely glamorous but it's what keeps the chain healthy and the developer experience good.
If you've followed my work over the years, you know what you're voting for. More of the same, but faster, and with a clear focus on making HBD useful enough to drive real demand for HIVE. Note that this list isn't exhaustive. I'll definitely be building more, but priorities shift quickly, especially now with AI, and we adjust month to month with the rest of the core team. For instance, once the light accounts specification is finalized, I'll likely lend a hand on the implementation side.
Voting
Here is an easy link to vote on the proposal:
https://peakd.com/proposals/371
https://ecency.com/proposals/371
You can view all proposals on:
https://wallet.hive.blog/proposals
https://ecency.com/proposals
https://peakd.com/proposals
(Make sure to vote on the upcoming proposal and not the old one!)
Closing words
If you have any questions, please feel free to ask them in the comments!
Let's address one of the biggest red flags in your proposal, your Syncad profile being private:
This should be an instant red flag and non-starter for people. I know you've done great work over the years and have been instrumental in some of Hive's development, but you expect people to fund someone who has their contributions to a decentralised blockchain set to private? Come on man, that just makes it look like you have something to hide.
There is zero reason to set your profile to private.
A 17% reduction is not good enough, sorry. We're in the AI era where devs of your stature can ship 10x faster, honestly, in your case it's probably higher than that (just based on my own experiences as a dev of 15 years and using AI). This is going to be a VERY hard sell. You're asking for over $100k USD a year for this proposal, but you haven't cleared up whether you're working 8 hours a day, 40 hour weeks for Hive. I highly suspect that you have a job already and Hive is a nice little side income for you, which is fine. But if you're going to ask for a full-time salary at a time when Hive is at an all-time low, that's poor taste in my opinion.
You contradicted yourself. You said it's misguided to focus pressure on spending, but then you point out the economics of software development thanks to AI are changing, meaning the cost of developing software is crashing and not as expense or exclusive as it once one. I don't think it's misguided, I think it's sensible we're focusing on spending, the Hive token price is collapsing.
Nothing you have outlaid in this proposal has provided any detail as to how you're going to go ten times faster or what you plan on doing beyond mentioning reputation system fixes, focusing on the content aspect and small fixes. We don't need any of that, we need big ticket items that bring in developers, make onboarding easier and improve Hive a whole. We've got so many UI's for Hive, it's just wasted effort focusing more on the UI aspect and like 98% of the content on this chain is AI slop now. Focusing on the content will kill Hive, it's zero value.
Also, being honest, a lot of the things you mentioned could be achieved in a month or so using Claude Code or other AI tools. You haven't mentioned anything that I can see requires extensive planning or complex development.
This isn't personal. I've been scrutinising all DHF proposals and expenses. You mention this is income for you and I am not against paying people what they're worth, but you need to update this post with your biggest accomplishments and sell yourself better. Saying you're planning on working on lots of small tasks isn't inspiring confidence that funding this is going to provide value.
I also take issue with the fact you're focusing on the content aspect of Hive, Hive is more than content. Sure blogging is the main showcase application of the Hive blockchain, but it's so much more capable and I think it's wasted development effort fixing up UI bugs and focusing on feeds and content discovery when Hive is missing lite wallets and still doesn't have an officially supported layer-2 solution, despite the fact the official Hive roadmap promises it in Q1 2026 (which I doubt will happen).
I highly encourage you to read the room, the bar is so much higher now. People are rightfully pissed off. The DHF has been rorted and abused for far too long. And I am not saying you're one of the people who have done so, I am saying the bar is just so much higher and your proposal really doesn't give any detail whatsoever as to how many hours you'll be working, the things you'll be working on and so forth. If you can edit the proposal and truly be transparent and provide realistic KPIs you can achieve, you'll have better reception and success with this.
You are reducing the proposal by approximately 17%, but coding costs have reduced way more by now. Given the severe situation Hive is in currently, proposals need to leverage the AI potential way more than that. Let alone breaking down the spent and showing more transparency. How can a proposal be so vague?
Specifically, what portion is personal compensation vs. other expenses?
If other expenses, which ones and how much?
Hi @howo, Your work and dedication over all these years are undeniable and evident. Especially over the last two years, which I’ve had the opportunity to witness during my still brief time here. (I even voted for your proposal from last year).
The fact is, times have changed, and proposals seeking funding from the DHF deserve a clearer presentation. Not to question the value and merit of this proposal, mind you.
Right after the last fork and HiveFest, there was talk of creating a single prototype/template for submitting applications to the DHF. It turns out that to date, we haven’t seen it yet. (It may have slipped my mind.) But proposals continue to be submitted just as they have been in recent years. I am not questioning the seriousness of each one, but the lack of rigor in the presentation leads to unfair judgments.
Since in my professional work I am accustomed to applying for public and private funding, I am sharing with you a suggested prototype/template, with essential items for submitting proposals for DHF funding.
I am convinced that if proposals are presented with rigor, everything becomes easier to understand and maintains a healthy environment.
If you clarify items 13 and 14, you can count on my humble vote. Because based on what I read in the publication, and knowing your work, I can fit all the other items into the template I suggested.
That's fair ! I think I didn't include a cost breakdown due to the fact that it's not a project as much as paying for my salary. So the cost breakdown is literally a one liner.
I think overall a lot of those templates that were floating around were never really used because they weren't "enforced" or agreed upon by stakeholders I.E "I won't vote unless you fill this template". And I don't think they ever will unless it's a value plan situation where a council/an individual decides on where to allocate money. On the broader proposal system there's plenty of different voices and no unified voting (which is a good thing)
I am of the opinion that it's better to let people make their case however they think is best and let stakeholders ask followup questions (like you're doing!)
The detailed budget is rather simple and the majority of it is taken by my own salary, all the other costs (hardware, servers etc) are from my pocket:
Monthly:
Claude pro max 20x => 200$
Full time contract work: 55$/hour, 8h / day => 8800$
In terms of cost justification, I'd argue that this is more than a fair hourly rate for a senior software engineer contractor in NA. And the 200$ claude subscription basically pays itself ten times over, I expect this to rise over the year as Anthropic stop subsidizing demand but I'll just shoulder the cost.
So you are working 8h a day for 20 days a month exclusively for hive?
Yes. Hive's my only source of revenue and job.
@howo, thank you very much for your feedback.
I’m sorry to disagree. It would be wonderful if future applications for European funding worked that way. But that’s not how it works. It is the applicant asking for the money who must explain how they intend to use it and justify their request. It is not the review and evaluation panel’s job to ask those questions. It is a basic rule that this information must be included in the application.
In fact, the applications I’m referring to are submitted via online platforms. They don’t move forward, nor are they accepted, if all the required fields haven’t been filled out. In the interest of rigor, whether in centralized or decentralized environments, there are items that must be included—and they are not being requested by the evaluators. That’s my opinion, based on my experience submitting applications for funding. Not at HIVE, mind you.
Some people don’t like asking “uncomfortable” questions. And those who do ask them sometimes do so in a tense tone.
As for the budget, it’s perfectly justified—given the country where he works. That’s just Claude’s price.
Proposal approved ✅
I wish you continued success in your work.
No I get it but that can't work on a decentralized system like the DHF
On that part fair enough. And if you create an anon account to ask then it becomes easy for the proposal owner to ignore them
@howo, the DHF has over 23M HBD. How much of it is going to be burnt?
Feel free to make a proposal to burn some, that's the beauty of it.
Glad you are here, howo.
Can we get bitchute.com and xcancel.com links to embed?
All the utub links get broken by my anonymizer so that utub doesn't get a list of what I have seen, so if the crowd had an option to utub, that would be great.
Xcancel is a nitter instance, it anonymizes x.com traffic, so that x.com doesn't get a list of all the things I see.
These things would allow a broader, more non-corporate conversation to the chain.
You mean on condenser ? It's slowly being phased out in favor of denser (it's replacement) so we wouldn't make changes there, I can take a look at it to have it on denser :)
That would be great, I just want to be able to have embeded links that work for me and my followers.
You got it! Happy to help you help us.
Much appreciation for your efforts @howo
Thank you !
Gran propuesta y muy completo el recorrido de tu aporte a Hive Core 🎯. Se nota que has estado profundamente involucrado en mejoras clave del protocolo — desde recurrent transfers hasta la reestructuración de notificaciones y el nuevo For You Feed — y que entiendes bien las necesidades tanto de usuarios como de desarrolladores. �
Hive
Valoro especialmente que estés abordando riesgos reales (como la inflación del HBD) con soluciones técnicas concretas y que estés dispuesto a ajustar tu propuesta (reducción de 17 %) en respuesta al contexto económico y al feedback de la comunidad. �
Hive
La visión sobre un feed de descubrimiento y herramientas de moderación más robustas realmente puede mejorar la usabilidad y retención de Hive, algo que muchos hemos señalado como prioritario. �
Hive
¡Gracias por tu dedicación continua y por compartir los planes futuros con tanto detalle! 💪
¡Gracias
There is currently a lot of debate about the risks of quantum computing for Bitcoin and cryptocurrencies. Is Hive addressing this issue?
Hi ! There's a lot of debate about those risks but realistically nonexistent for now. The paper is theoretical, not about actual hardware that could exist in the near future.
I'm not saying we don't need to tackle it, but it's a very low priority at the moment, we will watch what is done in the space research-wise and if the threat becomes somewhat credible we will shift priorities.
Thanks for the proposal - I appreciate all you've done for Hive over the last few years !
If you've followed any of my comments on other proposal/DHF related topics (although I appreciate I'm a relative nobody, so I won't be upset if you haven't 😁), you'll know I'm keen that proposals other than patching and maintenance show a financial business case together with clear metrics to measure success.
Also, and I appreciate it's outside of the scope of this proposal, that the DHF should convert to a loan-giver rather than a grant-giver for projects other than core maintenance, and that the proposal voting process is somehow modified to scale the vote required to the HBD asked for (in a way which doesn't support people just artificially separating a proposal into bite-size chunks).
In the case of your proposal, I actually wish it could be separated into three separate elements; ongoing support and patching (highly neccessary !), the "For You" feed (which I regard as a nice-to-have but not sure it'll do much to bring new users in), and the HBD infrastructure (which I regard as a potential big winner for Hive). But of course, running three proposals is harder to get voted through under the current process.
I actually think having a pretty much full time support/maintenance team should perhaps be outside the proposal system altogether - it's purely a personal preference, but I reckon my "dream team" would be yourself, @meno and @ecoinstant although there are lots of other worthy people out there too !
With the HBD infrastructure, are there any plans to create and market actual "real world" applications for non-Hivers ? I'm thinking a key market could be plugins for Shopify, Big Commerce, Bluepark, EKM Powershop, Magento etc - enabling e-commerce stores to offer checkoput-level payment options to customers in a variety of cryptos. HBD being fee-free and fast would be ideal for doing the heavy lifting behind the scenes. A small % on the exchange rates to and from HBD to BTC, ETH, fiat currencies etc would hopefully be enough to cover the costs and still offer cheaper rates than Worldpay etc on debit & credit cards. But since I run an e-commerce business, I admit it's one of my hobby-horses 😀
Hola me gusto mucho está información...
Todo es interesante, claro tengo que leer más.
Me gustaría poder conocerte y conversar contigo a ver si puedo colaborar en algo, no se mucho pero aprendo rápido.
Thanks for the update, @howo. As a small introduction and a bit of context: We're Innopay, a zero-fee payment system for merchants. We settle in HBD. The chain's payment layer is what our business runs on, so who maintains it and how they do it matters to us.
Content discovery and the moderation API are useful. We use PeakD as our main channel, and better tooling for communities makes that work better.
On spending: we'd gently disagree with framing it as speed vs. cost. We need both.
Projects like ours chose Hive partly because of how the chain governs its resources. Fiscal discipline attracts builders. Our revenue depends on the HBD savings rate staying where it is, and that depends on witnesses managing inflation well. Spending less and spending well are the same thing when the money goes to the right people.
Good work deserves funding. We hope the community backs this. 💛
Hi ! I appreciate the feedback and the work you guys are doing. I have expanded the scope of my proposal and it now includes a substantial HBD payment rails infrastructure work you might find interesting.
I agree this is also why I reduced my proposal funding from one year to the other :)
Thanks for contacting me. I will be happy to support your proposal 371. Take care.
Btw some things i would like to see ( Anon HBD on base layer/ pooled or default since no exchange use it anyway) + tradeable account creation tokens ( in case we come to a bullrun ever)
Thanks for the suggestions !
Anon HBD is quite complex to implement and would require a big redesign of the L1. I'm not sure I see that much use case for it and that comes with it's own set of regulatory issues.
I'd argue we could do a tornado cash fork-ish on Magi once their smart contract code is solid enough rather than implementing it on the L1 (though don't quote me on that I haven't checked magis' capabilities in a while)
Tradeable account creation tokens have been a feature request for a while but basically the rest of the core team (@blocktrades especially) are against it. Reasoning being that accounts are cheap enough as it is, that they should be removed because they were just a way for steemit inc to cheap out on paying account fees. Finally arguably light accounts are a better option for mass adoption as we can onboard millions without a big cost to the chain and only the ones who become "real" users will want to convert from a light account to a real account.
Light accounts also good. I look from the perspective of a dapp owner. Imagine you have a banger app, have a lot of hive ( but not enough) and now the price of hive is high ( whatever that means). So the 3 Hiver per account is pretty expensive on a scale at a higher price since the Dapp now pays twice, the marketing effort to onboard + the chain fee.
That makes Hive not competitive for a lot of dapps. Thats IMO a real problem since most people research before they build.
And anon HBD is more to make it like cash. A native algo anon stablecoin by default or not would be a banger product.
well my experience is ( what i see every day), be a software dev doesnt mean to be a good AI dev.
Would not wonder to see over the next years 2 different categories of it. to be real, i see "developer" using AI only to plan things... And not even efficent.
And this changes also the value. Not saying thats specific about you, but about the AI part. Everyone with a deep knowledge can 10x the work easy.
Yes but I'd still argue that my initial point stands, AI is a force multiplier and whether we disagree on the actual order of magnitude, it's still a massive improvement.
I was more making an overall point of "we should use it to spend the same amount of hours to do more rather than use it to do the same with less hours"
yeah 100%. But IMO the "core dev" team thats shieled from outside ideas ( or has most likely its own vision thats also not public known) should start to open the gate.
What i mean by this? At some point Ai code will be in any case better as human code. To get more people in know to have ideas and spend brain power + show what demand cases could be makes a lot of sense.
Since IDK non tradeable account creation tickets are really a feature. Not really prevents spam and doesn't add a market mechanic. Well if they are worthless ( that could be a problem). At least for a later point. Or at least allow them to donate ( another account to use them).
If something goes viral, you cant stop half way because you run out of stuff ( or highlight bad user experience).