[HN Gopher] Show HN: Launching Struct - Knowledge-Rich, AI-Power...
___________________________________________________________________
Show HN: Launching Struct - Knowledge-Rich, AI-Powered Chat
Platform
Author : mrjn
Score : 50 points
Date : 2023-06-22 14:32 UTC (8 hours ago)
(HTM) web link (www.struct.ai)
(TXT) w3m dump (www.struct.ai)
| vzaliva wrote:
| It is unclear how it deals with private channles. On our Discord
| server some channels have limited access and information from
| them should not leak outside the list of members.
| mrjn wrote:
| Right now, it only picks up public channels, because the
| Knowledge Base generated is accessible to public (so be careful
| -- do not add the bot in private channels).
|
| 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.
| anish_m wrote:
| Love the idea, and looking forward to using it. The unfortunate
| thing with slack and discord is that most of them are behind
| public search, and there is so much of lost wisdom for
| communities.
| alfredm wrote:
| Interesting framing, I appreciate your perspectives on knowledge
| in chat platforms. I've been looking at AI-powered searches over
| internal chats (such as Slack) myself recently. However, I do
| have to wonder a few things.
|
| 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).
| mrjn wrote:
| Hey! Thanks for sharing your concerns.
|
| 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.
| alfredm wrote:
| Appreciate the in-depth reply.
|
| 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.
| mrjn wrote:
| Re: pricing. You might be right, but on the other hand,
| most conversations might be limited to a few new threads on
| a daily basis. It's hard to know without actual numbers,
| which we'd only get after we onboard a bunch of companies.
|
| 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.
| ricklamers wrote:
| The unlock opportunity here is likely being underestimated. I
| heard once "you can be ahead of so many curves by being on
| Twitter", now add Discord and Slack.
|
| 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!
| ttul wrote:
| Interested to know how you plan to build a moat against Slack and
| Microsoft who are both building their own GPT-based systems to
| help manage chat-bloat.
| mrjn wrote:
| AI is helpful for Struct, but 5 out of 6 core principles for
| Struct go well beyond AI. Slack and other existing chat
| platforms score 1.5 out of 6 on CRISPY. Emails and forums score
| 4.5/6 -- Struct is designed to score 6/6.
|
| 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.
| mrjn wrote:
| I'm excited to announce the launch of Struct.AI -- a knowledge-
| rich, AI-powered chat platform.
|
| 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.
| cloudking wrote:
| No screenshots?
| mrjn wrote:
| Plenty of live examples though in the "Struct has Amazing
| Users" section, and on the website.
| SkyPuncher wrote:
| As feedback, you need them directly in the article.
|
| 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.
| mrjn wrote:
| Good point. Added a screenshot from Typesense Knowledge
| Base powered by Struct. Thanks!
| audessuscest wrote:
| you can't add private channels so I can't really test it
| mrjn wrote:
| That's the next thing we are working on. Support for private
| channels.
| jabo wrote:
| We've been using Struct's Slack bot in Typesense's Slack
| community here (if you want to see a demo of how it looks):
|
| 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.
| advaitruia wrote:
| Happy user here of the newly launched Discord integration :)
| haxzie wrote:
| Slack and Discord aren't built to handle knowledge. It's
| surprising how much of contextual knowledge is lost in ever
| ending threads and chats. Hope Struct changes that.
| iLoveOncall wrote:
| Chat is not meant to handle knowledge, that's it.
|
| 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.
| mrjn wrote:
| The issue is -- every email / forum platform which has tried
| to make IMs available within the platform has failed.
|
| Real-time, short-form interactions v/s async, long-form
| interactions is too wide of gap to bridge under one platform.
| maxwell201922 wrote:
| This looks like an exciting launch. We see so many pain points
| with Slack internally at Nutanix. We will signup for this.
| Excited to test the features!
| pranay01 wrote:
| We've been using Struct for SigNoz slack community. Here's how it
| looks https://knowledgebase.signoz.io/kb
|
| 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.
| vzaliva wrote:
| When organization starts using struct it will entrust you with a
| lot of confidential information. Assuming you also feed it to
| OpenAI the question arises on how it is protected. The privacy
| policy seems to written for an individual user. As organization
| admin I would like to see a privacy and information security
| policy for whole organization enrolling in struct.ai.
| mrjn wrote:
| "OpenAI will not use data submitted by customers via our API to
| train or improve our models ... Any data sent through the API
| will be retained for abuse and misuse monitoring purposes for a
| maximum of 30 days, after which it will be deleted (unless
| otherwise required by law)."
|
| https://openai.com/policies/api-data-usage-policies
| da39a3ee wrote:
| I really like the writing in the intro, but having "Horrible
| Search (of Slack)" as the first item in the justification for the
| entire product is a really bad idea and seriously weakens the
| argument. The trouble is that, even though you may be able to
| point to ways it could be better, in absolute terms it is
| incredibly useful.
|
| 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.
| fidla wrote:
| $37 a month
| ZeroCool2u wrote:
| This is a really cool idea and something I'd love to use,
| especially on large discord servers. Something that happened to
| me just yesterday was a friend of mine and I were trying to play
| a newly released game together and he was having a difficult to
| debug issue. The game is extremely popular and the dev team is
| literally 3 or 4 people. The main support channel is just a
| discord server, but that's incredibly hard to search for
| information about bugs and how people fix them.
|
| 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!
| mrjn wrote:
| Perhaps you could ask the devs nicely to install Struct Bot in
| their Discord server. I'm sure it would help the entire
| community to have a knowledge base.
| ZeroCool2u wrote:
| I have already, but my broader point was that this seems like
| a really common use case that could help with adoption and
| growth.
___________________________________________________________________
(page generated 2023-06-22 23:02 UTC)