Show HN: Launching Struct – Knowledge-Rich, AI-Powered Chat Platform
struct.ai
struct.ai
https://threads.typesense.org/kb
I love that the discussions we're having (in public channels) are now automatically indexed and made searchable publicly to any users who are looking for information on Google, etc, even if they're not a part of our Slack community.
I previously used to be worried about all this time and effort we're putting in to a walled garden of information that Slack was becoming, not to mention their untenable pricing for communities.
I now find myself spending more time writing more detailed answers in Slack, because I know it's going to be available publicly for future searchers.
Chat platforms today are inherently broken. Slack and Discord, the most commonly used chat platforms, while useful for real-time communication, create knowledge black holes, hindering the effective storage and retrieval of information.
I have thought about this problem for the past 5 years -- and arrived at a set of principles the ideal chat platform should aspire towards. And I've formulated all that into, what I call, the CRISPY framework.
I'm thrilled to introduce Struct -- a new, innovative chat platform fully embodying this framework. Struct challenges the status quo, turning real-time communication into accessible, lasting knowledge and reinventing chat as we know it.
As someone being dropped in from HN, I know nothing about your product and I'm not inclined to try to navigate. I need that content directly in front of me, with this article, if you want me to have any chance of seeing it.
Most blogs don't actually link back to the main marketing site (which is always a fail), so I've just stopped trying to navigate to other content.
This is exactly the kind of thing I'd love to see added to the server, so that finding the information in the massive chat channels I needed was easier and could be distributed to others.
If any Struct folks are around, the game is called BattleBit. The devs might be happy to hear from you!
Trying to shoehorn it in will only end-up in catastrophic failure.
The comparison shown in this very article should have led to the obvious conclusion that instead of trying to make chat suitable to knowledge-sharing, they should have made forums suitable for instant messaging.
Real-time, short-form interactions v/s async, long-form interactions is too wide of gap to bridge under one platform.
Personally, I'm happy for my chat app to be good at ephemeral instant communication, my forum to be good at longer-form async discussion, and my wiki to be good as a searchable read-heavy knowledgebase.
Also, you can remove the tediousness of Twitter feed scrolling because AI will make it easy to just ask for specific knowledge (if you know what you're looking for) or perform discovery based searching (what are some of the interesting ways in which people are using LangChain in this community). This is wild!
A few questions (haven't tried the product yet)
- Is it possible for the bot to summarize on slack, and drop a link to your UI? - does the bot have query / search capability through directly from slack? hopping into another UI at times can make it a poor experience ^ give your product roadmap, I am guessing this may not be on top of your list
- how does your bot know when a discussion thread has ended? Is the AI generation more a batch model today? - also does the bot handle merging two threads sharing similar context?
A few use-cases I believe this can solve right away - [more from engineering side] often times runbooks/dev solutions for issues can be generated from such discussions/threads. Your tool looks very promising to generate runbooks from slack threads. This kind of fits somewhere inbetween messaging-apps, stackoverflow & documentations (which is how I would use it atleast).
1. I'm working on adding Slack commands to the bot, so you can search, and even directly ask questions off the bot from within Slack. You're right that the need to switch to another website to find information is annoying -- in fact, that's where the full Struct Platform would be of incredible help -- one platform for chat and knowledge capture.
2. We sync the conversations every few hours. At that point, if there was some new chats in a conversation, we re-run the AI. So, it updates the title and summary according to the sum of all the chats the thread has so far.
The bot doesn't, but in Struct, we'd allow for a way to merge threads which are similar, or fork a thread which has deviated from the main topic.
For engineering, even sales and marketing, this would be amazing! I can think of so many use cases there -- for example, every GitHub issue, every sales deal, every customer issue, all could be threads in Struct, allowing easy communication with all the context readily available. The possiblities are VERY exciting! :-)
The last two companies I've worked at use Slack, so what I'm saying is based on something like 8 years of daily experience. Searching internal company Slack history is a fantastically effective way to retrieve information about other people who have confronted a problem similar to that which you are confronting today.
Yes, I absolutely agree that they're black holes in the sense that information that could go on the permanent public record is available only to a few, and then lost forever. But the problem there isn't search, so search shouldn't be the first item in your product manifesto.
Since, our community is so active, it helps a lot to have a tool like Struct to summarise discussions and have it for future reference.
But, we are very close to supporting access control, so the content would be private. And only the folks who're logged in, would be able to see it.
In fact, my thoughts on AI are that it would become a commodity. Every product would have AI -- so it would become tablestakes. It can't be the differentiating factor in the long term.
Did you do much research on competitors when coming up with 'scores' for them against your framework? You define
> Contextual Clarity: Each conversation should have a defined title and summary for immediate understanding.
And then for both Slack and Discord you give:
> Contextual Clarity | 0 | Bad. Must read each message to understand if it's relevant.
Despite the fact that Discord's threads are literally given defined titles (and indeed there's a whole forum style channel approach that is literally thread-first as Struct claims to be). I'd also argue that Slack threads are focused around one initial message which gives a fair amount of context to it, they aren't on their own.
Similarly you define:
> Isolation: Enable clear separation of concurrent conversations to maintain focus and avoid confusion.
Giving both products a 0 again:
> Isolation | 0 | Bad. Channel level isolation is too broad.
Even though both products have threads (not just channels) which are heavily used, and as mentioned Discord has given an entirely new channel type "Forum Channels"
Now, I know you come back to some of those points later on in the post (after giving a score that, in my opinion, is very misleading).
> Lately, Slack and Discord, have both added threads to allow some level of isolation. But, to achieve that, they had to break away from what made them special -- the liveness of conversations.
I mean, Slack has had threads for years and years, and Discord's aren't that new either. You then say that these break away from liveness of conversations and reduces them to numbers, and yet that seems to be what Struct does for every single conversation?
I appreciate this framework is very loose and you're trying to make a point to sell your product and way of thinking, but I find it difficult to trust you when you pose analyses such as these.
---------
However, despite all of the above, the thing I am most concerned about is your pricing. You're trying to sell it as "innovative" when you are literally charging $0.13 per thread, per month. The entire point of realtime chat-based applications like Slack and Discord is to facilitate fast moving, frequent conversation, rather than the slow responses of forums and emails. If Slack was constrained to being thread-first, you'd likely see tens to hundreds of threads a day for a tiny company, let alone a giant one.
I'd love to see if you're willing to post some estimates as to how much you expect your early customers' monthly bills to end up as. This feels extortionately expensive. (And just in case you think I missed it, I did read about "intelligently" forgetting threads but that feels so hand-wavy I don't even know how to address it, and part of having the history of something like Slack is that you can realise later on that you need information you previously said, even if you didn't think it important at the time).
First, most conversations in Slack or Discord happen as just chats in channels. Not as threads. The thread implementation that they have is actually a "hack" on top of their "chat in channel" design. I'm part of around 50-ish Slack and Discord communities -- to make threads work, the moderators have to manually enforce them -- tell the users continuously to keep things in threads. As a member of the channel, you don't get any notification, or any real-time update about what's going on in a thread, only a number. Discord's "thread-only" channels are a deviation from a chat platform, and a forum of sorts -- it's a hacky design, I for one, I don't like it.
You correctly point out that Struct also just shows a number -- but that's the knowledge base product (stage 1) of Struct. The chat platform (stage 2) would have liveness indicators, and threads would be presented in a real-time format.
For context, I have put an example in the blog post comparing a Slack thread against what would be the equivalent Struct thread -- the difference in context is stark. Note that these are chat platforms, so not all context is in the first chat message. Chat messages by default are short-form. It's only together that they add valuable context, not alone.
The thread based pricing would actually be much cheaper. Take Typsense community, they have thousands of users, but say 100 are active each month. That'd cost them ~$800 per month via Slack. They have ~600 threads right now, which would cost them ~$100 in Struct -- that's about an 8x difference.
Also, with Struct -- there's a huge "discoverability" factor -- so every new question doesn't need to be a new thread, it could share existing thread with the same topic.
I have no doubt, thread based pricing would be a lot cheaper. In any case, we'd be adapting the pricing model as things become clearer with usage.
I get what you're saying about the challenge of getting people to utilise threading well, but my experience (also in tens of communities) does not align quite as strongly as yours on Slack. There are frequent times where a reply goes in the channel as opposed to in a thread, yes, but in my experience that is far from the norm and isn't really a major issue. However, the threading approach on Discord definitely is less ergonomic in terms of starting one and I quite rarely see people utilise them in channels, that's true.
I can't say I understand what distinction you see between Discord's forum channels and the proposed behaviour of Struct's upcoming chat platform.
> would have liveness indicators, and threads would be presented in a real-time format.
I do get frustrated that Slack doesn't give a clear indicator of the last message, but Discord does have various ways of indicating that: "There are no recent messages in this thread." (literally just copied that from a thread on Discord), including having the forum channels be ordered by most recent updates.
On the topic of pricing, I could see it being better for large but inactive communities, provisioning a paid Slack workspace for an open-source project is often inviable after all. But for companies and teams that actively use Slack as their main source of communication, I'm not sure I'm convinced by the numbers right now.
Typesense seems to have had those ~600 threads in 4mo (the earliest one I can see on the index), which will be an ongoing monotonically increasing cost even if their users stagnate. However, I think those ~600 threads are not at all representative of the average entity that uses Slack for professional purposes; our Slack for example sees thousands of messages a day (a large amount coming from bots that we use to notify about various things) but I appreciate that is unlikely to be a use-case Struct is aiming to support. So if we ignore the bots, there are still tens of threads a day for a team under 10 at the moment, and many companies below 100 people will see hundreds of threads a day. If we assume a conservative 25 threads a day for 50 people, then in 4 months you'd see 3000 threads, which to my understanding of the pricing would be ~$500 in Struct, compared to ~400 via Slack.
I'll admit those numbers are actually a lot closer than I initially thought upon looking at your pricing, but that's assuming what I believe to be a very conservative amount for a few people, and giving up a lot of the other benefits of having Slack / Discord (interfacing with bots, getting other kinds of notifications), and after 8 months you'd be paying well over double without starting to "forget" a large amount of your history.
Over the course of a year, an active user would be charged ~$96 by Slack. At 13c per thread, that'd be equivalent of the user adding >700 threads in the year. I'd say that's pretty generous -- but, again hard to know without actual data.
Most importantly, if the pricing model doesn't seem to work for companies, we'll adapt. As mentioned in the post, we're exploring new grounds here in terms of pricing, and the ultimate goal is to find a pricing model that works for teams, communities and support. We're motivated by the underlying belief that the charging per user model doesn't work, and we need something better.