Some technical notes: This is actually a fork of Linen.dev, an SEO-friendly Slack alternative for communities. We originally built Linen.dev with Next.js but ultimately found it quite limiting when we wanted to make things fast and responsive and have custom caches. For Linen.team, there wasn’t a need for server rendering since we didn’t need our product to be SEO-friendly. We removed Next.js and replaced it with Vite and Express, which simplified our code quite a bit since we didn’t have the legacy requirements. We also spent quite a bit of time optimizing the performance and query so that it is much faster than the previous version of Linen. Our plan is to open source Linen.team as well; we need to do some repo clean-up first.
Finally, after a year, we actually reduced our client bundle size from 500kb to less than 400kb. You can see our post on bundle optimization here: https://news.ycombinator.com/item?id=35718417.
To be clear, this is not a dig, but I love that we're basically coming full-circle back to email, just without any of the decentralization and inter-tennant interoperability that comes natively to email.
All we need now is for someone to give every Linen user an externally accessible handle that allows cross-tenant invites or 'thread sharing' and we'll have officially closed the loop.
> We believe that most messaging apps are secretly to-do lists in disguise; you have to read, respond, or do some task when you receive a thread.
Perfect observation. Thank you for focusing on this reality. They aren't benign messages; they're summons, pleas, assignments, and to-dos.
Another small suggestion - 14 days seems way too short for a trial; most SaaS trials are 30 and I often end up emailing for extensions before onboarding a new vendor. This is not a cost skimp, it's to avoid making the wrong decision.
How does Linen compare to Zulip?
> 400 KB
Can/will you maintain this devotion to optimization when shipping a a desktop client? If it could not be Electron, that would be great.
I love the differentiation between ! and @. There are many times when I want to inform a group without bothering them.
Can this be self managed? Major plus if so.
Not everyone goes to the cloud by default. There are many orgs out there that want full data sovereignty for better infosec without relying on someone else's servers.
Ever hear about Levels by Derrick Reimer? Seems like this is trying to accomplish the same thing. He eventually shut it down though. Looks like you got YC funding though so that’s huge!
Pricing is a tricky endeavor but personal opinion --- $9 per user per month is a little excessive just for messaging compared to the competition.
> threaded messaging app
I hated threads in slack when they were introduced. However, as with a lot of things (new site designs etc) it helps to give them time to settle in before you decide if you really like them or not and I'm happy to report that now after several years have passed since they were introduced I still absolutely hate slack threads.
They are one of the worst parts of slack. They are where information goes to die, they are easily missed, they are cumbersome to deal with. I would disable them if I could.
Perhaps they work well with huge teams, but I've worked in companies with tens and hundreds of engineers and they have been an unecessary hindrance.
This looks really nice. It’s similar to Slack, but still has it’s own distinctive feel.
The ways in which slack is different from IRC are it's worst features, as a developer. The fact that you've told us that you're focusing on what makes it most different from IRC is not encouraging.
Awesome! I’ve been desperately looking for a slack alternative. In part I want something more lightweight, and nowadays there are so many little upsells that get in the way.
My biggest use case is talking to people on other teams (Slack Connect.) How is that managed here?
Also, what is the narrative around adding users and billing? I hate that every time I add someone to slack for a project need to make a buying decision (are they a full user, guest user, active vs inactive…) Is it possible to pay for users when they’re active, and not have to worry about managing seats when projects end?
Going to check this out for funzies. I do love Slack threads but not something you can force. Discord threads have much to be desired in their UX/UI. My least "favorite" of theirs in fact. Losing the colocation of information is extremely negative impacting to an organization.
Slack's UI with activity and all that went down significantly from their latest update. Shocked they haven't switched back. Community feedback from what I gathered is extremely unhappy users.
When I sign up it asks me for a display name, but after I sign up it has completely ignored that and instead added the part before the @ in my email address.
Any reason you're using rest for a chat client? Maybe socket scaling limitations of the node/express stack. Not as bad as php whci slack is still mostly written in, but hard to beat the mostly Erlang stack for discord. It also makes it's lot easier for bot dev having a two way connection without the hassle of ngrok etc.
Very interesting, I was looking for a lightweight team collaboration tool yesterday. I like ClickUp/Wrike/etc. but even their home page feels slow, before signing up.
I wonder if there are any alternatives to you and how you compare to them.
Is there a way for automations to post messages with web hooks? That's usually the easiest automation-type feature to implement on the platform and for users
Any tests done on scaling? How’s the search? Maybe because of the nature of slack but I use advanced filters very frequently to find old messages.
How do you distinguish your product from Twist? I like the two levels of mentions, but that's not enough to convince me to jump by itself.
Here is Mix0r, a thread-first "Messageboard for Anything" type site: https://www.willashani.com/gigabots/db. I built it because I wanted to use a site like Twitter but with messageboard-like threads. I also believe that every post belongs to a thread so it can be easily referred to. And I too, think think that a thread-based app can be used like a todo-list. I have some examples there.
Do you have any plans to release a desktop-compatible bundle?
[dead]
[dead]
[flagged]
I have no words to describe how bad is the ! and @ distinctions: it means you give control of your notification to other people. I can see it abused 100 different ways (and if you do build for large teams, and don't expect abuse, then you're either never been on any large enough service, or never talked with anyone in a minority group).
If this is just a replacement chat tool, it's fine - and a great start.
But if you want to replace Slack, you need to focus on the developer community and third-party integrations right now. We're not paying for something that only gives us "just" chat with better-by-design UX and chat workflows. Teams is free and fits this purpose, at least in the eyes of an executive.
Slack's developer environment (outside of Grid features, the new "Premium Workflows" and "Next Generation Platform") is first-class.
At the very least start with some webhook integrations.
Also your Privacy Policy has no mention of Amazon Web Services, I think you might want to review your "DATA PROCESSORS / SERVICE PROVIDERS" section.
Also, are you planning on offering single-tenant options? Not a fan of our chat data sitting with a bunch of other organisations.