I would recommend to keep working on this. I'm interested in this space, and also contributing. Are you looking for collaborators? I think if you continue to iterate on this, there will be value, because these problems do need to be solved.
I would also recommend to create Standards for the new Protocols you are developing. Protocols need standards, so that others can do their own implementations of the protocol. If you have a Standard, someone else could be building in a completely different language (like rust or go), and not use any SDK you provide, but still be interoperable with your AAP and AIP implementation for smoltbot. (because both support the Standards of the AAP and AIP Protocols).
I also want to note, you cannot trust that the LLM Model will do what your instructions say. The moment they fall victim to a prompt injection or confused deputy attack, all bets are off the table. These are the same as soft instruction sets, which are more like advice or guidance, not a control or gate. To be able to provide true controls and gates, they must be external, authoratative, and enforced below the decision layer.
Hey! I launched AAP and AIP via Apache specifically because I want independent implementations built on top of them. I have a pretty killer roadmap of new features for both protocols coming out that will keep them on the bleeding edge. Love to see what you come up with.
On standards, I totally agree. There are those who will disagree, but my view is that we are rocketing towards a post-internet agent-to-agent world where strong and reliable (and efficient) trust contracts will be the backbone of all this great new functionality. Without that, it's the wild west. AAP and AIP are extensions of Google's A2A protocol. FWIW, I have submitted papers to NIST, the EU AI Act's section 50, written alignment cards for the WEF standards proposals, and have an AAIF proposal ready as well. Need to find the time to get on their calendar and present. That was the whole point of the hosted gateway approach. Trying to reduce the friction of using this to one line of code.
On the point of not trusting the LLM, you're preaching to the choir. My "helpful" agents routinely light my shit on fire. AIP is not a soft instruction set. It's external to the agent. checkIntegrity() is code, not a prompt. The way I implemented it with smoltbot is a thinking-block injection that nudges the agent back on track. That's all, live on our website using our AI journalist as dogfood.
On the last part, who watches the watchman, I'm going to append to my initial post. Check this out...
I don't view freemium as a business model, I view it as a distribution model. The distribution model changed from paid to free. This usually results in a user base that grows faster but pays less. By making the app free you've set an expectation of not having to pay. This attracts a certain type of customer, which are usually much harder to convert. If you're trying to build traction for investors this might not matter. If you are trying to monetize then this does matter.
The business model changed from a one time purchase model to a micro payment model. My recommendation would be to try a monthly payment model for v3. Let the users pay to access the service (setting an expectation to pay for value) but allow them to pay less than what you perceive to be the cost barrier (the amount you believe is the maximum amount they would pay to give it a try). I'm going to agree with others that you are priced too low. One of the best lessons I've learned is that it's not what you think it's worth, it's what your customer thinks it's worth.
I'm not sure about non-Engineering roles, but this somewhat reminds me of my experience interviewing with Facebook for a Network Engineer position. Traditionally, Network Engineers are experienced with Vendor provided solutions (Juniper, Cisco, etc) and most interviews would cover experience implementing/supporting different types of architecture using these Vendor provided solutions. Facebook Engineering exemplified a refreshing new approach where Network Engineers are also Software Developers, and the focus/goal is to proactively correct and automate Network Engineer tasks. This means there is less time fighting fires, and more time building solutions. I found this to be an interesting new approach (for me anyway). So conceptually, I could see this working; an HR person that can write the company HR tools, marketing and sales people that write their own tools, etc.
It does not matter what platform you choose (web or mobile), bad developers develop bad software. For every horribly designed, slow, bloated website you find, you can likely find a similar horribly designed, slow, bloated native app. I'm sure you've heard of garbage in garbage out. I view development as a craft and like most crafts, not everyone has the same level of skill. This does not reflect on the platform people choose. It reflects on the people themselves, their time investment, work ethic, priorities, approach, methodologies, etc. Like with most crafts, there is usually more than one way to accomplish something; some more eloquent than others. At a very basic level, both web and native apps share many commonalities; some sort of UI being rendered and interactions with data via API calls. As long as you can reach your goal, does it really matter how you got there? How about this; the debate is ridiculous. They both rock (or suck depending on your perspective).
I whish this phrase would die and be replaced by bad "teams" produce bad software. I have worked on some projects with fantastic developers, but awful or no UX, or a misguided vision, rushed to market etc etc.
I have also worked on projects with awful awful code base but the end product is actually alright (so long as it doesn’t need any maintenance).
Perhaps we should flip it on it's head and say, "good technology doesn't guarantee good software".
Many companies and teams had a "web hammer" and went looking for things to nail even when that made no sense. At the peak of the web frenzy, web apps were going to kill desktop apps, and one could feel the pity when web devs were talking about desktop and mobile apps. And now... someone finally stops and thinks that maybe it's not such a great idea to turn everything into a web app.
When a group of individuals takes such a strong position and they are proven to be wrong, I personally think some crow eating is due :-)
In my opinion, the best way to promote your app is with word of mouth advertising. Unlike other forms of advertising, you can't buy word of mouth advertising; instead you need to build something that solves real problems and creates true value for your customer. The bigger problem you solve, the more value you have. A high perception of value builds loyalty, and lays the groundwork for customer advocates (which are your most important customers). When your customer talks with other potential customers that have the same problems, your app or service becomes a potential solution. Word of mouth advertising is powerful because recommendations from friends and peers carry more value than traditional advertising. Potential customers are more likely to try your app or service when it's been recommended by friends or peers. This is most effective when it occurs naturally (not forced). These are lessons learned from my first startup (results of our product, customer reactions, customer surveys, etc)
I agree; I think the concept has potential, but it was never executed properly. So it's still kind of vague in terms of what the value might be. I also agree with the comment about context. Hit the nail on the head. Without context, it just becomes useless noise, no longer any value.
I disagree; I think it's a great idea that has (still) never been realized. The implication of Ambient Social Discovery is real-life interactions. It is an online to offline transition of Social Media. Traditional Social Media has created somewhat of a Social Oxymoron; People sitting next to each other staring at their phones to satisfy Social wants and needs. Ambient Social Discovery has the implication of connecting people sitting next to each other, put the phones away, and have the opportunity to satisfy Social wants and needs in person, in real life. This is why I disagree with the 'stupid idea' comment; In my opinion, this is a literal example of leveraging Technology to increase real life capabilities (in this case, enhanced Social awareness and knowledge). The reason it didn't work is because it was not executed properly. It did not provide value. It creeped people out
Disclaimer: I bootstapped a competitor to Sonar, Highlight, and Glancee during this time period, but we never made it to Launch (problems with execution). My opinions above are based on all the (exhaustive) customer validation work that was performed.
That could be deliberate, though. People may deliberately want more boundaries from anonymous means of communications. They post on Reddit instead of Twitter when they don't want folks to know who they are; they tweet instead of text when they don't want to address any particular person; they text instead of call when they want to downplay awkward pauses in the conversation or hide that they're multitasking; they call instead of videochat when they don't want the other party to see their facial expressions.
The customer validation results you got could be explained by a prestige hierarchy in social interactions. In general, addressing people directly and hiding as little of yourself as possible signals higher status, because it implies that you are less ashamed of who you are. Nobody's going to say "Yeah, I'm a hermit who spends all my time trolling people anonymously on Reddit", they'll say "Yes, of course I want higher quality face-to-face interactions." But when it comes to their moment-to-moment decisions, very often they would rather troll people on Reddit.
My own personal opinion; The concept of Ambient Social Discovery should have been approached with more sensitivity towards the Users privacy. Lots of people were kind of creeped out by the concept; it was just too personal. Because of this, people were less likely to give it a try. I believe this placed the Ambient Social Discovery space into somewhat of a fringe Service, where technologists and early adopters were willing to give it a try because it's cool from a Technology standpoint, but your average Users wouldn't try it out unless their Friends had used it (aka it had caught real Traction, chicken and the egg). So this kind of put Sonar (and others) in a bad position because not only do they have the regular challenges that every Startup faces, they also had to deal with a negative perception of the concept in general (which was forward thinking at the time). I believe this greatly influenced the growth rate and adoption of many Ambient Social Discovery Apps/Services.
Disclaimer: I bootstapped a competitor to Sonar, Highlight, and Glancee during this time period, but we never made it to Launch (problems with execution). My opinions above are based on all the (exhaustive) customer validation work that was performed.
I would also recommend to create Standards for the new Protocols you are developing. Protocols need standards, so that others can do their own implementations of the protocol. If you have a Standard, someone else could be building in a completely different language (like rust or go), and not use any SDK you provide, but still be interoperable with your AAP and AIP implementation for smoltbot. (because both support the Standards of the AAP and AIP Protocols).
I also want to note, you cannot trust that the LLM Model will do what your instructions say. The moment they fall victim to a prompt injection or confused deputy attack, all bets are off the table. These are the same as soft instruction sets, which are more like advice or guidance, not a control or gate. To be able to provide true controls and gates, they must be external, authoratative, and enforced below the decision layer.