Talkyard: Open-Source forum software – a StackOverflow, Reddit, Disqus hybrid
github.com
github.com
Is there documentation somewhere? I can see it has some kind of spam protection by skimming the source code, but I don't see any docs.
Will check this out.
(If / when you find things that don't work like you want, I'd be happy for any feedback: https://www.talkyard.io/forum/ )
I'm looking to build a forum/discussion for a non-technical audience with some of the policies that HN has implemented well... community will be non-monetized, but it'll be connected to a separate, sponsoring monetization channel.
I've not actually spent a lot of time on a Discourse forum, but have liked some of the plug-ins they support, and the wiki topic element, the ability to theme it, and the ability to limit or lock categories based on karma and groups. FYI on where I'm coming from.
How interesting — what would your community be about? (if I may ask)
Non-tech people is a long term goal with Talkyard.
As of now, though, I'm thinking none of Talkyard or Discourse or Flarum (did you know about Flarum? https://flarum.org) or Nodebb are particularly easy to use, for non-tech people? E.g. Markdown for formatting text, and navigating between topics and categories, feel confusing to me.
> Discourse [...] the plug-ins they support, and the wiki topic element, the ability to theme it, and the ability to limit or lock categories based on karma and groups
Some of those things, but not all, work with Talkyard: 1) Wiki topics / categories — yes, by configuring category permissions (see this reply here: https://news.ycombinator.com/item?id=22704726 ). 2) Locking categories based on groups and trust levels — yes (see the same link). 3) Plugins: No, unfortunately not. I think there'll will be a WebAssembly based plugin system in the distant future. 4) Theming: Can be done but not so easy — one needs to write CSS code. A theme & colors editor is planned.
> liked some of the plug-ins they support
I'm curious about which plugins :- )
> messages are folding individually (i.e. only content is hidden but not the children)
Seems like a nice way to give a concise overview of the discussion (who replies to who, how long each thread is). I think it'd be nice to see the first rows of each message, so one knows what it is about (maybe one has forgotten).
> only new messages are shown in an unfolded state
(So that one directly sees the messages one hasn't read before, and can start reading them effortlessly, right)
> only new messages are shown
I wonder how they determine which messages are new. Maybe it's [new since one's last visit]? Or messages one hasn't read yet? Not that easy to know which messages the visitor has read, if many messages are visible on the screen at the same time :- )
I doubt that you will find it particularly useful (site in Russian, and I've no idea how reliably that feature works for unregistered users), but anyway: https://www.opennet.ru/forum/
> I wonder how they determine which messages are new. Maybe it's [new since one's last visit]?
It is. While not as powerful as status tracking for individual messages (can't skip some messages for future read as easily, can't mark message as unread etc.), it is enough for most users most of the time.
Nice to be able to "preview" a discussion directly on the topic list page, and interesting shortcuts the forum has:
Открыть первые 10. — Open the first 10. (I used Google Translate)
Открыть последние комментарии. — View recent comments.
Раскрыть ответы 1 уровня. — Expand Level 1 Answers.
Линейный вид. — Linear view.
> It is [...] enough for most users most of the time
Ok, thanks, interesting to know
What things would you want me to focus on, when adding documentation?
(How would you like to use it / maybe integrate with sth else?)
(Rather than how to install the software? For that I hope the readme file works ok.)
Hmm, you mentioned Scala and the JVM — I'm wondering if you have in mind "Getting started" with editing the source code
(I'm curious about what forum software you used in the past, as an admin, and how did you like it?)
Any special API things / features you'd be interested in? E.g. API for doing X or integrating with Y?
(I've fixed the "e2e-test-" prefix problem, will deploy in a few days. Was unintentional — I would have removed the "Create test site" link instead)
https://blog.codinghorror.com/the-rise-of-the-electric-scoot...
the comments in the comments section, are from Discourse. Here's that Discourse forum: https://discourse.codinghorror.com/t/the-rise-of-the-electri...
A difference between Talkyard and Discourse, for blog comments, is that Talkyard is threaded, like Disqus. So when people start talking about different things related to the blog post — start different "sub topics", then, with Talkyard, each such sub topic gets its own sub thread,
... Whilst with Discourse, all sub topics are mixed together into one single flat layout.
And, with Talkyard and Disqus etc, the more interesting (more popular) sub topics are shown first, whilst with Discourse, it's whoever happened to type the first comment, who is shown first.
For those interested, There's already another initiative for a free, non-commercial, community-governed StackExchange alternative, called codidact: https://codidact.org/
I don't know that it's good (or bad), I just know there's been planning work going on around it, following the recent upheavals and resignations on the StackExchange network.
(And also I'm less familiar with those other tools; there're good things about them that I don't know about)
No Activity Pub support, ...
... It'd be nice if some day in the future, Talkyard could pull in toots (tweets) from Mastodon and show as posts in a discussion forum topic, or as blog post comments (after having been approved by a moderator).
What Fediverse software do you use the most? Like the most?
I believe there are efficiency gains to be had from having a unified platform that is self hosted.
Looking at your list of tools, seems to me GitLab will stay "forever", and... Mattermost is probably always going to be a better chat,
I'm thinking maybe a Mattermost + Talkyard (+ Gitlab?) integration somehow, could make sense
What about Sharepoint, you use it for document management?
Scala/JVM - a bit too heavy for something simple as this. The system requirements are ridiculous. Why not implement similar things in Go? Gitea vs GitLab performance and ease of deploy is the best showcase for these tasks.
Yes that's what I would have done, if I were to start this project now. Well, not Go, but Rust.
Edit: what this implementation of threads lacks though is an ability to fold all sibling messages before the one that I'm interested in, so that I can have a quick look at the context and avoid a lot of manual scrolling and folding myself. Most implementations (like here on HN for instance) only do folding of child messages, which I personally find a bit less useful.
I've been thinking about that — after all, Reddit with its concise design, is pretty nice.
I'd want there to be an optional concise theme, so Talkyard could look more like HN or Reddit, for those who prefer that.
> fold all sibling messages before the one that I'm interested in
Where could be a good place to place a Fold-all-siblings button? There is a Fold-whole-thread button already at the top of each post, to the right of the author name (it looks like: ^ and to un-fold: v ), ...
... but if one has scrolled down a bit, and want to fold all siblings, when the parent post is a bit away, then, could be impractical to have to scroll up to it, and click a button up there?
Maybe clicking the arrow could open a power user menu, with "Scroll to parent" as the default, and also a "Collapse siblings" button?
Example: If you go here: https://insightful.demo.talkyard.io/-9#post-24 and click the arrow to the left, maybe this poweruser popup menu could open?
And / or you have other ideas? :- )
The problem is that in very large threads it's quite hard to remind yourself about the context of the conversation that you're currently reading: you either need to scroll a lot to get to some grand-grandparent and back, or start manually folding messages above, one by one, subthread by subthread, until the context gets uncluttered.
Let met illustrate what I was describing: https://i.imgur.com/pm1SIRJ.png?r (You could imagine way more replies in those shaded areas—a situation that is not that uncommon here on HN.)
Thanks for showing / clarifying. I have the precise same problem (here at HN mostly).
> "show me every parent message prior to this one"
> Sibling folding is just one of the ways to implement that.
3 ideas:
1. What if, at the top of the page, there were buttons like "Scroll to parent"? So that when you look up, to see if you can see the parent post there somewhere, then, instead you see a "Scroll to parent" button. — Once one has scrolled to the parent, maybe to the grandparent, there's a Back button to scroll back down and continue reading.
2. What about keyboard shortcuts? If you click 'P', the page could scroll to the Parent. 'P' once more, scrolls to the grandparent. 'B' scrolls back down to the parent, 'B' again scrolls back so you can continue reading. (But how would Talkyard know which post, of many, you're reading, if the screen is large? How know which parent, of many possible, you have in mind? Maybe there could be one Scroll to Parent button per indentation depth)
3. A button "Show ansectors", for every post. Click it, and Talkyard would popup a dialog, with all ancestors (parent, grandparent, ...) and you could scroll up-up-up inside the dialog and have a look, and close it, once you're done reading — without affecting your scroll position on the "real" page.
That just would not work on smartphones.
> But how would Talkyard know which post, of many, you're reading, if the screen is large
One way is to implement arrow-key navigation and highlight current message in some way (border, bgcolor or whatever), but I'm not sure if that would work well outside of some special keyboard-centric navigation mode designed to cater to fans of software like mutt or vimperator.
Zulip comes to mind: in there selected message affects what topic people are going to reply into, and if people are not used to that feature (or to the idea of chats with topics in general), they can easily dismiss or fail to notice that very selection and treat the input box just like they would that in any other chat app, which would result in misdirected replies. Some teams are fine with spending some time babysitting the conversation (change topics of other people's replies after the fact, teach colleagues how to use that particular software etc.), but others would just switch to simpler software, with flatter conversations and/or less navigation features.
> 1. What if, at the top of the page, there were buttons like "Scroll to parent"?
Do you talk about the very top of the whole page (scroll position 0) or about sticky header at the top of the viewport? If it's the latter, then it's going to be as problematic as keyboard shortcuts (i.e. can't decide which message's parent we need to jump and where to return to).
> 3. A button "Show ansectors", for every post. Click it, and Talkyard would popup a dialog, with all ancestors (parent, grandparent, ...)
That implementations seems to be both the most robust and the easiest to implement.
> That implementations seems to be both the most robust and the easiest to implement
I think so too. I'd like to implement it.
If you want to, you could send me an email (see my profile)? Then I can send you an email, once I've built this ( >= 2 weeks), if you'd like to see how it works & maybe have feedback
\* * *
> arrow-key navigation and highlight current message in some way
I've thought about that some times. Could also be nice for people with accessibilyty problems? (e.g. shaky hands, keyboard navigation better than the mouse pointer)
If the screen is small, e.g. on mobile, Talkyard could probably be pretty certain which post one is currently reading, so might work ok well, automatically.
> not sure if that would work well outside of some special keyboard-centric navigation mode
Yes, maybe this would be for power users and people with disabilities.
> but others would just switch to simpler software, with flatter conversations and/or less navigation features
I suppose such power user navigation things, should be disabled by default.
\* * *
> sticky header at the top of the viewport?
Yes
> going to be as problematic as keyboard shortcuts (i.e. can't decide which message's parent we need to jump and where to return to).
This is also related to highlighting the post one is reading — there'd be one specific parent post to jump to, when pressing 'P'(arten).
Could also experiment with mouse pointing on a post, to make it the keyboard target. And then pressing 'P' to jump to its parent.
\* * *
> Zulip comes to mind: in there selected message affects what topic people are going to reply into [ ...] result in misdirected replies
Now I'm wondering if this is a reason why e.g. Mattermost is more popular than Zulip.
Maybe it's not only that Mattermost is better at marketing (are they?) but also that they are less "power user focused"?
Modern smartphones easily fit a couple of comments on a screen, at least here on HN and on that forum that I mentioned in the other thread. Heck, I just dug out a 3rd-gen iPod Touch just to see how these websites look on its comparatively small screen. The result is that even devices with comparable screens (think iPhone 4S and other phones of that time) can occasionally fit a number of one-liners or, depending on a font size, a couple of longer comments.
The trick might still work though if you prefer much larger fonts, but otherwise smartphones don't make this feature easier to implement.
----
Speaking of mobile: I once experimented with showing replies one at a time. It did a good job at keeping the context around, looked and worked well on mobile devices, but I'm pretty sure it would make harder to find new comments, skim over discussions (and, say, find interesting/insightful comments just by scrolling around), and probably worsen experience in some other way. You can have a look over at https://vthriller.github.io/tmp-hn-comments/carousel.html
> Could also experiment with mouse pointing on a post, to make it the keyboard target. And then pressing 'P' to jump to its parent.
People often prefer keyboard navigation because they want to minimize palm movement as much as possible, and that means reduction of mouse usage as well. Aside from that, if mouse is in your hand already, you might as well click on an on-screen button near the comment—that would be faster than bringing palm back to keyboard.
You might want to try to mitigate that by switching binding to a key on the other half of the keyboard, so that it can be pressed with the other hand, but even then only a handful of people that spend hours navigating through threaded comment jungles will teach themselves to use both input devices to aid reading threads, and it's hard to think about anyone that can fit into that category. (At first I thought about on-duty moderators of traffic-heavy forums, but they don't usually need that much of a context to notice violations.)
However, you made a good point about accessibility earlier: people with some sort of impairment might win from that kind of hybrid navigation mode. But would it be easier for them than, say, keyboard-only navigation? This area needs much more research.
> Maybe it's not only that Mattermost is better at marketing (are they?) but also that they are less "power user focused"?
Familiarity plays a significant role here. There's plenty of chat apps that look and behave in a similar way, so it's easier to pick up or switch to another one if you so desire.
Have you considered adding a feature like this?
How will / do-you-have-in-mind-to verify people's identities?
Talkyard (like Discourse) has Single Sign-On via API — so you can have an external piece of software that somehow verifies people's identities, and Single Sign-On connects to Talkyard and upserts those verified users (like @nerdbaggy wrote).
With Talkyard, the SSO API looks like this: Your own piece of software sends `POST talkyard-server/-/v0/sso-upsert-user-generate-login-secret` plus JSON for an external user. Then you get back a login secret, and you can redirect the end user's browser to `talkyard-server/-/v0/login-with-secret?oneTimeSecret=...`
\* * *
@jimkleiber you asked @nerdbaggy:
> not sure which service you use to do the identity verification. Could you say a little more about how you did it?
I'm thinking @nerdbaggy meant s/he Single Sign-On integrated with Discourse? But maybe didn't actually verify people's identities. Those are two different things, and I'm thinking likely you'll need to come up with your own way to verify people's identities (?)
Will you be bringing on other developers, opening up to other contributors? My only worry is the dependence on just you KajMagnus. Amazing job so far!!
> bringing on other developers, opening up to other contributors?
Yes that's the plan, definitely
This far, some people have contributed translations. I think right now it's a bit complicated to get started with writing source code and running tests, and there are some refactorings and renames I started but didn't finish yet, making the source code directory structure a bit confusing.
(If you have ideas about how / where to find people who might want to try to contribute, it'd be interesting to hear)
I think that's a good idea. Maybe the next steps for finding contributors, isn't to find a place on the Internet where many want-to-be-contibutor-to-something hangs out, but instead have better docs and to-do lists for those who find their way to Talkyard already somehow.
> bringing in other devs is a huge step
I think the first contribution tasks would be to just find out where they get stuck, when they try to get something done. And then I'll remove such "roadblocks" one at a time, until people can actually get things done. — Maybe this means many small steps :- )
These people: [All Members v]
may do this:
:
[ ] Edit other people's topics
[ ] Edit others' comments
[x] Edit one's own stuff
[ ] Delete others' topics
:
:
- Group ownership of particular topics or sections of topics. This allows for things like "anyone on the team responsible for project X can edit/moderate things regarding their project"
- History of edits made to topics, linked to author. It's incredibly valuable organizationally to be able to see the evolution of knowledge, as well as provides protection from content deletion, both accidental and malicious.
Talkyard does the things you mentioned, although it's not so discoverable: Most people don't think about clicking their way to the Category | Security settings, and looking at the checkboxes, and thinking about how to combine them to create a Wiki.
Maybe Wiki features could be listed on the homepage, or at least in a feature matrix. And, when creating a new forum topics category, one could get a question about if it's going to be a Wiki topics category.
* * *
There's one Wiki feature that Talkyard lacks though: Easy linking between different pages. At Wikipedia, for example, one types: '[[Target page name#Target section|Link text]]' — there's nothing like that in Talkyard.
A wiki main page shortcut link somewhere would be nice too (e.g. in the left hand sidebar).
(I'm curious about if you use wikis where you are now, which Wiki software, and how do you like it?)
A few remarks:
- It would be nice to have a button to collapse replies for a given comment, but not the comment itself.
- On mobile (andoid), it is bit laggy.
Thank you for open-sourcing.
(I keep adding new buttons and labels, and renaming things, so the translations get out-of-date / fallback to English.)
There's RTL support but no Arabic / Hebrew / etc translations yet.
* * *
> It would be nice to have a button to collapse replies for a given comment, but not the comment itself
Yes :- ) Do you mean 1) for yourself only, or 2) for all site visitors (so those replies would be collapsed by default, for everyone) ?
Actually there was a feature for 2, in the past, but it's disabled now though. The database fields are still there, plan to make that code work again some time in the future. (Then you could manually "curate" a discussion, by collapsing all replies to certain posts, to make the reading experience better for your site visitors.)
* * *
Can I ask which Android version and phone do you use? — I optimized Talkyard a while ago, by looking in Chrome Dev Tools, but this was on my laptop.
What things lag the most? (Some specific button(s) or animation or scrolling or ... ?)
Rather for myself, but as an account setting so that I don't have to collapse them manually for each thread. Actually it stems from something that bothers me with HN: when there are a lot of nested replies, I lose track of the which comment corresponds to which parent. For example, try reading this thread : https://news.ycombinator.com/item?id=22705222, I find it difficult.
If there are 5 comments (level 0), that each has 10 replies (level 1) and each one of them has 10 replies (level 2), I wish I was able to collapse level n>0 replies to read the comments first, then be able to unfold level 1 replies for the first comment, while keeping level 2 hidden, and so on. This might not be the ideal solution, maybe simply the way you added arrows to replies would make the above thread easier to read.
> What things lag the most? (Some specific button(s) or animation or scrolling or ... ?)
I just found it's not specific to android (I'm using Android 10 on a recent galaxy smartphone). Mostly animations. On the desktop version, If I click on the plus button near 'Chat Channels', the login window is show progressively, and the background is dimmed in way that 'feels' slow. Also when I unfold a collapsed reply, the page moves slowly (is there a reason it moves ?). When I click reply, a window is shown, 'loading draft...' appears then disappears quickly and then the preview is highlighted, it somehow feels slow.
Me too, here at HN. When I'm reading on my phone, looking at reply R to a parent post P somewhere far above, and I want to re-read P — then I place my finger to the left on the screen, at the current indentation depth, and scroll up up up, past the even-more-indented-replies above ... until the indentation depth becomes 1 step less than my finger. Then I've found the parent comment :- )
Problem is, how do I find the reply R again. And, sometimes I accidentally move my finger, losing track of both R and P.
In Talkyard, one can instead click the arrows to jump to the parent, and the Back to jump back to the reply R — here's a demo about that: https://www.talkyard.io/-32/how-hacker-news-can-be-improved-...
If you want to try this yourself, go here: https://www.talkyard.io/-71#post-16 then click the long arrow to the left, then click Back at the bottom of the screen.
> unfold level 1 replies for the first comment, while keeping level 2 hidden
Something like that, yes. At the same time, since popular / "good" replies are sorted first, I think it can make sense to unfold a few of the level 2 replies, for the topmost level 1 replies — so one needs to click fewer times, to read the "most interesting" things. But these are minor details; I agree with the overall idea.
> Rather for myself, but as an account setting
Ok. There're also custom user groups — so a site admin could configure this setting for the Everyone group, and then one could override it, individually.
\* * *
>> what things lag the most
> Mostly animations [...]
Ok, thanks for the detailed feedback. I think the code is doing things too much sequentially — like, first loading any draft — an X * 100 ms round trip to the server. Then scrolling the post one replies to into view, Y * 100 ms, then scrolling the preview into view, Z * 100 ms (so both are visible at the same time, if possible). — If instead everything happened at once, it'd seem more instant.
(Also, there're editor Javascript:s that JIT-compiles and runs the first time one opens the editor.)
No
> because you like them?
Yes (the software, ... and the company & founders & employees I like too, & their visions)
But anyway, it’s impossible to tell from just the package.json file whether React and jQuery are being used on the same page, or just both used in different parts of the app.
Actually, when I was starting with React, then for a while Talkyard did use both jQuery and React on the same pages (not a good idea, I agree). I was careful to avoid the bugs you have in mind from happening, so that wasn't a problem,
however, loading & using both libs wasn't good for performance — just parsing and executing the 30 kb min.js.gz jQuery bundle took maybe half a second? a second? on mobile phones, back at the time (2.5 years ago).
edit: and it still is today, just a tad updated: https://reactjs.org/docs/integrating-with-other-libraries.ht...
Thanks for the link. I think I saw that page, or sth similar, back then. ... Now I found an old question I posted at StackOverflow about jQuery + React: https://stackoverflow.com/questions/27646347/is-it-okay-to-d...
I use Bliss.js, https://github.com/LeaVerou/bliss for some parts of Talkyard nowadays, where React would be too much. Bliss.js is sth like 3 kb min.js.gz. (But jQuery itself is gone nowadays, it was too large.)
I would seriously consider dropping this dependency. React's performance is fairly acceptable.
I agree that React is fast enough. React is pretty large though, takes a bit time to parse and compile the code, on mobile. And none of its features are needed in this case, and could instead cause conflicts with other libs.
What I'd do, if anything, is a custom build / fork of Bliss that removes most of the code, so 3 kb becomes Bliss maybe just 1 kb "Mini-Bliss".
Ive left projects and come back to find the developer between had done things like, pull in a library to handle slideshows when one already existed. Things like that.
however the dependency was still there ... Now I'm removing it.
In the beginning, there was only jQuery. .... Then, for a while, there was also Angular, and for a short while, a tiny bit Angular Dart (I got on the hype train?).
Then, there was a month removing all Angular things, and switching to React. And then ... Another month removing all jQuery things.
There's still a disabled way of laying out a discussion in 2D, using the full width of the screen (nice with a 30'' monitor :- )) and then, for horizontal scrolling, jQuery was used. But all this 2D stuff is disabled nowadays (I like the 2D layout but it's a rarely used power user feature and I was too short of time so had to disable it).
(The reason I removed jQuery, and use React only, was to improve performance — just parsing and executing the 30 kb min.js.gz jQuery bundle took maybe half a second? on mobile phones.)