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.
No worries. I was just curious, having done some forum admin in the past...how you approached spam. I would guess a "getting started" doc would be the #1 priority. Especially since the server is Scala, and many may not have worked with a JVM.
Pretty awesome, what about APIs? Also there is a problem/bug in creating test sites. "Site name has to start with e2e-test..." but no way to enter that prefix. Might temporarily intentional
Re: finding new comments, I've seen another solution on one of the news site forums that I quite liked: messages are folding individually (i.e. only content is hidden but not the children), and when you enter the thread through the "new" link, only new messages are shown in an unfolded state.
It'd be interesting to have a look at that news site forum (if you have a link?).
> 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 :- )
> It'd be interesting to have a look at that news site forum (if you have a link?).
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.
A bunch of interesting things going on at that forum, Opennet.ru/forum :- )
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.
Sth like the expand-level-1-answers button is something people have suggested for Talkyard too.
> It is [...] enough for most users most of the time
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.
That's not a FOSS StackOverflow, it's a cross between several platforms.
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.
Looking at that homepage, I have zero idea about what it does or even looks like. It seems to be all mission statement fluff and no description of the actual tool.
Anyone know how the self-hosting experience is? Also whether it has Activity Pub support? If this reaches it's potential, it would be great if it were part of the Fediverse.
From what I've heard, people like the auto self-upgrade feature.
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?
Space looks super promising, but I looked at the EAP in late January and it seemed far from ready for actual use. It seemed like it needed another year in development to flesh everything out. I really hope it comes together like they plan for it to. It'd be nice to switch from our stack of Redmine, 2 instances of GitLab, Slack, and a custom wiki solution.
> You need about 6 GB RAM for the development environment (whereas the production environment needs about 2 GB). And an internet connection — you'll download perhaps 1 GB Docker images and other files.
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.
I've been using the hosted version of this (https://www.talkyard.io) on a blog for a while and have been very satisfied. I like how the threaded discussion looks, and also like the live preview edit box which works well for long form comments.
I'm not a fan of the style that threaded discussions have (too much padding, and I'm not sure about arrows too), but I always wanted to experiment with that sort of arrangement of messages, where long chain of one-on-one replies does not get pushed to the right but instead have some sort of linear representation. Will definitely have a closer look on that software.
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?
I think "show me every parent message prior to this one" would be a better way to describe the feature that I occasionally miss in every implementation of threaded conversations. Sibling folding is just one of the ways to implement that.
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.)
> remind yourself about the context of the conversation
> Let met illustrate [...]
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.
> 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"?
> 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.
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.
I've been looking for a forum software that would let me have verified identities for my users, either restrict the forum only to verified users or even let users optionally verify themselves, and I haven't found one yet.
Nice, I see the link talks about SSO with Discourse but not sure which service you use to do the identity verification. Could you say a little more about how you did it?
@jimkleiber, Discourse, and Talkyard too, also have settings for Require-manual-approval-of-new-users. And restricting signups to whitelisted email domains.
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 (?)
Have been running Talkyard as a sandbox for a month and it's great.
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)
Would it be possible for you to list out some of the easier tasks that you have on your to-do list, and solicit coders to work on those. i know that bringing in other devs is a huge step, but you've put together a very solid platform, and it'd be great to see it keep growing.
> list out some of the easier tasks that you have on your to-do list
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 :- )
Two important aspects of being a wiki replacement, especially at a larger scale:
- 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.
Thanks for the feedback! I've never edited a wiki as a member of a large organization.
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?)
There's multilingual support yes, and user contributed out-of-date translations to Brazilian Portuguese, Russian and Polish
(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 ... ?)
> Yes :- ) Do you mean 1) for yourself only, or 2) for all site visitors (so those replies would be collapsed by default, for everyone) ?
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.
> I lose track of the which comment corresponds to which parent
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.
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.)
What? Is this really controversial? Sometimes you need a UI library, sometimes you need really quick interactivity to toggle a menu. I use alpine.js on my marketing pages, and I use vue/svelte within sections of my app.
Using them on separate pages is fine, but using React and jQuery on the same page is usually not a good idea since React needs to “own” its slice of the DOM and changing things in there with jQuery could cause weird bugs.
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.
Now jQuery is gone (see my other reply just nearby, in this same comments tree).
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).
Alpine.js looks nice, didn't know about it. Light-weigth React/Vue/etc for just 7 kb :- )
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.)
Actually to me, Bliss not getting new features or changes (just maintenance by Lea Verou), is a good thing. Upgrading libs and breaking changes, takes time — stability is nice :- )
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".
the problem is that react and jquery both need ownership of the DOM. if you have code that mixes them, it is recipe for disaster.
subtle hidden bugs start creeping up.
My blind guess is; one hand not know what the other is doing.
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.)
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.