Veritula – Meta
Discuss Veritula itself. For feedback and suggestions.
Log in or sign up to participate in this discussion.
With an account, you can revise, criticize, and comment on ideas, and submit new ideas.When all I change during a revision is the criticism flag, the activity log just says ‘no changes’.
As of 9702c05, a revision activity now says that the idea was either marked or unmarked as a criticism.
Hi all! This platform looks like such an awesome idea!
This discussion says, "Discuss Veritula itself. For feedback and suggestions."
I wanted to ask about how many members are here. And whether it's encouraged to invite more people, in order to add more and more conversations.
Should probably show the explanation in a revision, when given. In the activity feed, that is.
Should I give the icons in the activity feed colors?
The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms just like when they are child ideas.
When a comment is a criticism on another criticism, the activity should say ‘So and so addressed criticism #…’
In activity feed, behind timestamp (‘… hours ago’), link to corresponding discussion.
Since the diff processes the text as a single line, the hunk header is always going to say either @@ -0,0 +1 @@ (for the first version) or @@ -1 +1 @@ (for every subsequent version). Meaning the header provides no real information. So I might as well remove it.
Done as of 8d3eed0, see eg the version history of #414.
There’s a bug where hovering over a link in the markdown preview removes the form and all typed text. Hovering over a link should have no effect on the form.
Now that there are user profiles (#408), each profile can have a tab for unproblematic ideas. Among all the ideas a user has submitted, those are the ones he can rationally hold. And another tab for problematic ideas, ie ideas he has submitted that he cannot rationally hold.
Then people could occasionally check the second tab for ideas they think they can rationally hold but actually can’t. And then they can work on addressing criticisms. A kind of ‘mental housekeeping’ to ensure they never accidentally accept problematic ideas as true.
Would be neat linking to a specific activity.
Each activity should have a distinct HTML title. The browser history and search results in search engines all look the same…
There’s a bug where right-clicking in a form to paste text doesn’t result in the preview updating.
Dirk Meulenbelt says the concept of revising someone else’s idea is not intuitive.
The following commits should address this:
3af3966Clarify in title that someone revised an idea (rather than originated idea)The HTML title now says ‘Idea x revised by…’
6c70ceaUnderneath idea, indicate that someone revised an idea (rather than submitted it)It says ‘Dennis Hackethal, 1 day ago’ for new ideas, ‘Dennis Hackethal revised 1 day ago’ for revisions
d20d386Explain that users can revise each others’ ideasAs part of the alert on the revision page, when the user is about to revise someone else’s idea.
c5748e3Turn ‘revise’ link into ‘revise their idea’ when it’s someone else’s ideaUnderneath each idea.
e0fbd41List user under each revision in version historySo that each version is clearly attributed to the corresponding user.
06d3241List contributors at top of version historyComma-separated list to see all contributors at a glance. Eg see here
Tom Nassis asks (#448):
I wanted to ask about how many members are here.
Currently 7.
And whether it's encouraged to invite more people, in order to add more and more conversations.
Yes.
The more ideas there are in a discussion, the further the form for top-level ideas is pushed down. Then people don’t know how to submit a new idea and comment on an existing one instead, even if it’s unrelated, as happened with #448. So I need to make this clearer.
The way IG solves this is by rendering the form in a fixed position. It’s still on the bottom but always remains visible.
Reddit is a bit different because they have multiple subreddits/communities, but each community has top-level posts which people can then comment on. They have a completely separate page/UI for top-level posts. And then directly underneath a top-level post, there’s a textarea saying “Join the conversation”.
Any progress on this? Scrolling to the bottom to submit new ideas is annoying.
Yes, see here: https://veritula.com/discussions/veritula-meta
Give it a shot.
It might make sense to have the new top-level idea form at the top, in the meantime. Compared to the current design, this would invite the creation of more top-level ideas.
There could be a floating button on the side that takes you to the bottom of the page.
There could be a side pane that stays visible while scrolling content.
No room for that, at least not on mobile.
Done as of 4922b8c. The form now sticks to the bottom of the discussion page.
Now that there are notifications, people should be able to @mention each other.
Mostly done, apart from some polishing, as of 5f5c545. Eg @dennis-hackethal.
I'm still getting a feel for this platform. I'm wondering whether it would help promote wider and deeper engagement if Veritula was organized in terms of problems and their solutions. So instead of discussions, discussion trees, and broad topics such as 'Abortion', users would articulate problems and their solutions. Of course, the problem itself could be criticized as well as its proposed solutions. This approach might also make Veritula even more Popperian. All life is problem solving as Popper says.
As I recall, previous iterations of Veritula had explicit designations such as ‘problem’ and ‘solution’ but I decided against continuing those designations. It’s been years but I think it was too rigid and felt too much like ‘red tape’. It’s easier when the only check box in this regard is a boolean for ‘criticism’.
Can’t discussions already map onto the structure you suggest?
Discussion title: problem
Top-level ideas in the discussion: proposed solutions
Nested ideas: criticisms, counter-criticisms, and further solutions
Note also that revisions act as solutions to problems. So do counter-criticisms, in a way.
So I think people can already use Veritula in the way you suggest.
They can also use it like this:
Discussion title: some topic (such as ‘abortion’)
Top-level ideas: problems
Nested ideas: solutions, criticisms and so on
Makes sense to me.
'Discussions' is a much broader term than 'problems and their solutions.'
So I can see how that would allow for greater freedom.
I can also imagine some of the challenges presented in prior iterations of Veritula, if it had more of a 'problems and their solutions' structure.
Perhaps some of this theory of problem-solving just shared can make it into 'How Does Veritula Work?'
Yes, I do think discussions can map onto the structure I suggest.
So, no worries. I was wondering whether the 'Discussion Titles' can draw in current and future users in a more frictionless manner with problem statements.
But if it was tried before, why try it again? Thanks.
You marked this as a criticism but it sounds like you’re agreeing with me.
Perhaps some of this theory of problem-solving just shared can make it into 'How Does Veritula Work?'
Done, see #510.
I was wondering whether the 'Discussion Titles' can draw in current and future users in a more frictionless manner with problem statements.
I think you’re right, that would be best.
You suggest replacing discussion trees:
[I]nstead of […] discussion trees […] users would articulate problems and their solutions.
But then you also write:
Of course, the problem itself could be criticized as well as its proposed solutions.
Which means you’d still have trees regardless. So that sounds like a contradiction.
To be clear, I'm not opposed to 'trees' in general.
I was wondering whether 'discussion trees' can be replaced with 'problems-and-their-solutions trees' (for lack of a better phrasing).
Veritula should have a section with a list of all its current members.
For now, people just have profiles.
But having a list of members would build a sense of rapport between the participants.
And would promote a greater flow of communication.
Good idea. I’ve added this to my list of features to implement.
Done as of 6251b6a, see veritula.com/members.
[H]aving a list of members would build a sense of rapport between the participants.
Just so you know, although I’ve implemented the list of members, I do want to be clear that Veritula is not meant for socializing.
I know what you mean, but Veritula unavoidably facilitates public (i.e. social) interactions, no? Of a certain kind, to be clear. Ideas, ideas, ideas.
Well, discussions are necessarily a ‘social’ activity in that they involve at least two people, yes. I just don’t want Veritula to be yet another social network.
In a mixed society, people can prioritize truth seeking or fitting in but not both.
Need email notifications.
See #595. The form for new ideas is pushed to the very bottom of the discussion page. For long discussion, that means users won’t know where to submit new ideas.
Newly added comments keep animating when hidden and then unhidden.
All emails have unsubscribe links, but people shouldn’t be able to unsubscribe from system emails like password resets.
Friendly IDs for discussions would be nice. With automatic redirects for numeric ID from legacy links.
Include (preview of) content in idea URLs: '/ideas/123-first-30-or-so-chars-of-idea-here'.
That would make idea URLs more meaningful, but there’s something simple and beautiful about the shorter URLs that only have the numeric ID.
Could have backwards compatibility for the short version and continue using the hashtag in the UI. Best of both worlds?
That would mean fetching an idea to compute the path for each hashtag. Overhead?
Seems like minor overhead. It’s not like there are tons of user-generated hashtags everywhere.
This actually helps to prevent rendering links with IDs that don’t point to any existing idea.
Having features to both collapse an idea and hide all its comments seems like an opportunity for unification. Why not just go with collapsing and remove the ability to hide all comments?
Cycling through the revisions of a leaf reveals its gutter, which should be hidden since it’s a leaf.
Make sure cycling between a leaf revision with children and a leaf revision without children properly toggles the gutter.
Feature to collapse all criticized ideas of a discussion? Useful for todo lists.
Or each discussion could have a search/filter form to filter ideas not just by criticized or not but also content and potentially other attributes.
Or the existing search page could be filtered by discussion. For example, I could link to that page with an additional query param discussion_id=1 or something like that.
When you revise an idea to address a criticism, its author should get a notification so they get a chance to verify that the revision really does address the criticism.
For example, I had to manually notify Edwin in #1811 of a revision I had made to address a criticism of his. Without this notification, he might miss the revision. If he disagrees that the revision addresses his criticism, that’s a potential error that might not get corrected.
The new subscription system takes care of this.
There should be a feature similar to the ‘single comment thread’ feature Reddit has, where you start with some deeply nested child idea and render all of its deeply nested parents above it:
G
/|\
P1 P2 P3
\|/
I
This feature would be great for seeing an idea in its proper context without having to scroll past a bunch of potentially unrelated ideas.
For parent ideas, cycle only through revisions that lead to the target idea. Communicate accordingly in the UI. For the target idea, its children, and any of its siblings’ children, cycle through all revisions.
Every idea should have a link to a separate page with the single comment thread. This could just be ideas#show. That page should also scroll the target idea into view in case its preceded by too much context that would otherwise push it below the viewport.
This feature would also allow me to remove the buggy ‘context’ feature.
The red ‘Criticized’ label shows how many pending criticisms an idea has. For example ‘Criticized (5)’ means the idea has five pending criticisms.
But if there are lots of comments, including non-criticisms and addressed criticisms, it’s hard to identify pending criticisms.
There should be an easy way to filter comments of a given idea down to only pending criticisms.
The red ‘Criticized’ label could be a link leading to a filtered version of ideas#show.
The red ‘Criticized’ label could be clickable and filter the displayed comments ‘in place’.
That would probably be stretching the capabilities of Stimulus…
Should I be showing the comment form by default on ideas#show?
To avoid scrolling past content, I could remove the autofocus on the textarea unless a certain query parameter is given.
The ‘Revise…’ button is hidden when the comment form is open. It makes sense to hide it because it doesn’t belong in that context. But once hidden, the user has no quick way to revise an idea. Maybe the first thing they want to do after opening ideas#show is not comment but revise.
As of acb14e3, the revision button is an icon button that lives next to the collapse icon button.
Therefore, the button doesn’t need to be hidden anymore.
That would mean the revise button would be at the top of the idea. But presumably, people would typically want to revise an idea after they finish reading it. Meaning after they reach the bottom.
It could go both ways. Someone may have already read an idea and just wants to revise it, in which case having to scroll to the bottom is cumbersome.
Having implemented this, a problem has surfaced: when linking to an old version of an idea, the alert “You’re about to comment on an old version of this idea. Are you sure …” shows. That’s jarring if you didn’t want to comment but merely look at the idea.
Add hover effects to schemed buttons so there’s consistency with the existing hover effects for links.
https://veritula.com/activities/1808
Since the discussions starts with an idea, there should be a reply button.
Bug: when clicking the link to the activity in #1953, the idea is replaced with “Content missing”.
The displayed criticism count for a filtered parent can differ from the number of displayed criticisms.
Any filtered idea should always display only the count of shown criticisms.
That could mislead people into thinking a revision has no pending criticisms, which would be bad for error correction.
The instructions at the top of the page are clear that not all ideas are being rendered.
For all ideas, the total number of pending criticisms (if any) should always be shown, even if they are not all being rendered. For filtered parents, I could put an asterisk behind the count. On hover, explain that some pending criticisms may be hidden due to filtering.
Any filtered ideas should show a criticism label displaying n / m for the count, where n is the number of rendered criticisms and m is the number of total criticisms.
An explanation could accompany the n / m display, like a title on hover.
That way, there should never be any confusion as to a mismatch between the total vs rendered number of pending criticisms.
In addition, when looking at a deeply nested idea on ideas#show and submitting a criticism on a parent, I need to make sure the updated badges take into account that newly submitted criticism, even though the new criticism would not show after refreshing the page.
I have this working to the point that it shows n / m, but getting the counter to update properly when new criticisms are posted on filtered parents is surprisingly difficult – so difficult the juice may not be worth the squeeze.
For any filtered parent, the criticism badge could be shown without a count.
I could get rid of the count everywhere, even on unfiltered views. That would have the added benefit that users wouldn’t prefer one problematic idea over another just because it has fewer pending criticisms.
Still, the count is valuable in that it shows how many criticisms need to be addressed to restore an idea.
By the time someone receives an email notification, they will probably have forgotten whatever they wrote originally that prompted someone to reply to them.
Fixed as of recently. Emails now quote the parent idea.
Veritula should have some way to indicate agreement; some way to indicate that a particular thread of a discussion is resolved, at least for the time being.
People could wrongly think they have epistemological relevance. For example, they might adopt an idea that has pending criticism just because it got positive reactions.
Reactions could be limited to the recipient of a comment.
That limits the scope of the problem but doesn’t eliminate it. A single recipient could still react in a distracting way.
There’s value in reacting to top-level ideas, too.
There’s value in others being able to react as well. Maybe an idea affects them in some way or they want to voice support.
The red “Criticized” label is far more prominent than reactions would be.
Reactions can be ambiguous. It wouldn’t always be clear which part of an idea someone is reacting to.
I could implement reactions on a per-paragraph basis.
It isn’t clear what would happen during a revision. A paragraph might be changed or deleted. Too complicated.
But presumably, the same is true for reactions to ideas as a whole. Reactions would have to be removed for revisions.
For reactions to paragraphs, at least you could tell if the content someone reacted to has changed, and only then remove the reaction.
Why should reacts persist through revisions?
Then what does somebody do who wants to react to an idea as a whole? Do they react to the last paragraph?
The way I picture it, as you hover over different paragraphs, a reaction button appears and moves between paragraphs. So it would always be clear that reactions are on specific paragraphs. The user would pick whatever paragraph they most wish to react to.
The purpose of the reaction would be to record a kind of agreement or acknowledgment.
That way, Veritula could show ‘pending’ criticisms to users, say – ‘pending’ in the sense that they haven’t responded to those criticisms. So in addition to revising or counter-criticizing, they get a chance to accept a criticism without it remaining in a ‘pending’ state.
Posting arbitrary emojis doesn’t achieve that purpose.
This is a good idea.
I often receive criticisms that I have no counter-criticisms for, and it would be nice to be able to acknowledge those, both as a way to display gratitude, and as a way to indicate that I think something is tentatively settled.
The Effective Altruism forum has an interesting way to react to posts.
There’s an ‘Agree’ button and a ‘Disagree’ button. Those are apparently anonymous. Then separately, there’s a button to ‘Add a reaction’ of either ‘Heart’, ‘Helpful’, ‘Insightful’, ‘Changed my mind’, or ‘Made me laugh’. And those are apparently not anonymous.
I wonder why they chose to make some reactions anonymous but not others. I don’t think I’d want a ‘Heart’ or ‘Made me laugh’ button, they seem too social-network-y. Also, ‘Heart’ seems like a duplicate of ‘Agree’. But ‘Insightful’ and ‘Changed my mind’ seem epistemologically relevant. Maybe ‘Helpful’, too.
If I did decide to go with ‘Agree’ and ‘Disagree’ buttons, I wouldn’t make them anonymous, though.
Revisions are complicated. Too many options (superseding a previous version, ‘Is criticism?’, unchecking comments). It might help to have a more guided processes over multiple screens.
I started a discussion earlier, and what I wrote in the “about” section of the discussion was not written well. I would like to revise it. Is this possible? If not, is there an intention to make this possible eventually?
I notice that when I amend a criticism I have made, I’m not able to see what I am criticising. It would be good if the edit screen showed the comment I am disagreeing with similar to how it does when I first go to write a criticism.
Feature idea: private discussions only the creator and invited people can see. This could be a paid feature; $2 per discussion, say.
What happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?
There could be hard cutoff: they lose access to everything, including their own ideas in that discussion.
But that sucks. Maybe someone works hard and submits a bunch of ideas only to lose access to them all.
That risk could be clearly communicated in the UI.
This functionality is pretty standard across apps. You can be removed from Discord servers, Telegram channels, etc without warning or reason at any time. People generally know and accept this. If they still put in effort, that’s on them.
What if they still have subscriptions or bookmarks in that discussion?
Those could be deleted when the user is removed.
If the discussion owner accidentally removes someone and then adds them back right away, it sucks if all the associated records are still gone.
In later implementations, I could maybe implement a ‘soft’ delete or grace period. Or I could keep the associated records and rely on authorization rules to prevent access. But as of right now, that’s a premature consideration.
They could keep access to their own ideas but not see others’.
There’d probably be a bunch of edge cases with this approach. For example, others would still be able to comment on those ideas, and the comments would have to be hidden from OPs. Which begs the question of how that impacts the displayed criticism count… And so on.
How would you notify participants of changes to the privacy setting?
The activity feed already shows updates to discussions. Could just include changes to the privacy setting there. And, whenever the privacy setting does change, notify participants of the change.
This is done as of 9b5788c but it’s still free for now. Will make it a paid feature after some more testing and polishing.
Feature idea: selecting some text, then hitting ‘Comment’, automatically pastes a quote of the selected text into the textarea, Telegram style, with the proper Markdown formatting.
Bug: tooltips sometimes don’t disappear. They should disappear when the user stops hovering over the element that triggered the tooltip.
I can still reproduce the issue by clicking on the button to collapse/expand an idea.
Discussions are getting slower to render as they grow. It’s a rendering issue (not a db issue).
I could cache ideas so deeply nested trees can be rendered at once.
I could lazy load ideas: only load the parts of the page that would be visible on the current viewport. Then load more parts as the user scrolls.
On initial page load, I could just load the first ten or so top-level ideas and their immediate children, just to reduce wait times and populate the page. Then load the rest asynchronously.
I could use ActionController::Live to stream top-level ideas to the page one by one. Instant page load.
Including that module significantly slows down hot reloads on all pages. I need a tight feedback loop in dev.
After resetting my working directory and beginning to implement streams a second time, I can no longer reproduce this issue, despite reasonable attempts to reproduce it.
I’ve since been able to reproduce the issue after all. Running a raw SQL query in Idea.tree in combination with the inclusion of the Live module seems to mess with Rails’s reloader.
Replacing a raw SQL query in Idea.tree with a standard ActiveRecord query solves this issue.
This page used to take ~3.5 seconds to load. Now it renders within 600ms :)
Incompatible with Devise authentication: https://github.com/heartcombo/devise/issues/2332
The thread suggests a workaround: use authenticated do … blocks in routes.rb instead of before_action :authenticate_user! in controllers.
It’s probably a good idea to do this anyway to avoid divulging the existence of routes that unauthenticated users don’t need to know exist. (They will get a 404 instead of a 401.)
Then again, I’d want to redirect users to the sign-in page (and then ideally back to where they were trying to go).
I could extract discussions#show into a new, separate StreamController or something like it. That controller would not use Devise.
JS modules are always deferred and unusable until the page is fully loaded. As a result, comment buttons and gutters won’t work while ideas are still streaming onto the page.
I now purposely prevent interactions with buttons and gutters, and gray them out, until the page is fully loaded. So instead of broken hover effects and interactions, the user gets intentionally disabled elements, and this intentionality is communicated to them.
Once the page is fully loaded, buttons and gutters are enabled and visually restored.
Since the browser’s loading indicator remains visible until then, this behavior shouldn’t violate user expectation.
cmd + f won’t work reliably.
This problem will surface rarely – users would have to hit cmd + f immediately upon opening the page. For most users, by the time they start typing, the page is already fully loaded. So this seems like a small price to pay in exchange for discussion pages that always render faster.
I could have a separate route at /ideas/:id/isolated which renders only the idea without any parents or children. And then a discussion could render a bunch of deeply nested turbo frames loading that route.
For large discussions, wouldn’t that flood the server with requests?
The top level ideas could be rendered as turbo frames of ideas#show.
I just tried this. Seemed promising at first but sometimes ideas load out of order. Looks horrible.
I could render the first ~10 top-level ideas immediately and only render the rest as turbo frames off screen. By the time the user scrolls down, they should all be loaded.
Too many requests when there are enough top-level ideas.
Automatically generated ideas are polluting the search page.
As of 2d3d38f, system-generated ideas are excluded from search results. They can be included again by checking a new checkmark in the form.
Would be nice highlighting strings matching the query in search results.
Feature idea: page at /ideas/:id/guide which shows you an idea and helps you address all pending criticisms one by one, if any. At the end, it shows a message ‘You’re all set!’ or something like that.
On the search page, there should be a button to clear the query input.
Changing the query on the search page moves the cursor to the start of the query input. It should move to the end or, ideally, keep its position.
In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black gap underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear; seems to be a Brave quirk.
This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.
I could simply give the footer the same background color as the rest of the page. There’s a discrepancy between light and dark mode anyway. And on horizontal overscroll, the difference in background is painful.
‘Veritula’ is a difficult name, people don’t know how to spell or pronounce it. They can’t easily remember it.
Idea: ‘The Second Renaissance’, ‘2nd Renaissance’, ‘2R’ for short.
‘Renaissance’ isn’t exactly easy to spell either.
Idea: ‘Reason Arena’, ‘RA’
I like something with ‘Arena’ because it would imply action, some ideas winning out over others, and has a Darwinian aspect to it. Our best ideas are the tentative champions in the arena of ideas, waiting for the next challenger.
I have largely inexplicit criticisms of the word ‘arena’ in this context, but one that bubbled up to the explicit level is that the word reminds me of Pokemon for some reason 😅
Idea: ‘Conjecture Arena’, ‘CA’
Old ideas can pollute discussions. Like in this meta thread.
Proposed solution: edit a discussion to hide top-level ideas. That way, discussion owners can hide ideas they no longer deem relevant.
For example, completed tasks in discussions used as issue trackers, like this Meta thread, could be hidden so they don’t pollute the thread.
There could be a button for users to reveal hidden ideas so nothing is lost or hidden dishonestly. And direct links to hidden ideas would continue to work.
Proposed solution: ideas with pending criticisms could be archived automatically if they haven’t had any activity in the past 30 days, say.
Proposed solution: allow people to archive ideas. Maybe only their own.
Autofocus should put the cursor at the end of an input, not the beginning.
Done for the search input as of 765ba05. It makes sense for that input because the user expects to be able to keep typing after submitting the form. For other inputs, the user will expect whatever default their browser implements.
Search page is getting slower the more ideas there are in the db.
https://veritula.com/ideas?q=&nature=uncontroversial is down from 2988ms to 476. Growing db should now have marginal effect, if any.
Idea: Activity feed should track when you last visited it, take you there when you open it. Currently, someone like me who likes to see everything happening on Veritula needs to go back through pages to find the last thing they saw.
As the site grows and there is more activity, there would be too much going on for any user to be interested in all the activity on the site, so it would eventually become irrelevant
That’s what notifications are for. You’d want to hit the bell icon for each discussion and at the top of the page listing all discussions. Then you’ll be notified of every activity on existing discussions, and of new discussions. The notification page keeps track of read vs unread notifications.
Idea: Discussion specific activity feeds
Done as of a12ffb3, see eg https://veritula.com/discussions/veritula-meta/activities and the new link to ‘Activity’ at the top of each discussion.
Idea: Veritula Articles
Currently, Veritula is a discussion website. I believe it could one day do what Wikipedia and Grokipedia do, but better.
A step towards that would be enabling users to produce ‘articles’ or something similar.
An ‘Articles’ tab would be distinct from the ‘Discussions’ tab, featuring explanatory documents similar to encyclopedia entries, and perhaps also blogpost-like content.
Articles focus on distilling the good ideas created/discovered in the discussions that occur on Veritula.
‘Articles’ are functionally no different than top-level ideas in a discussion thread.
Top-level ideas in a discussion thread are not standalone pages.
One thing that Wikipedia does well is having a structured, high level page for each idea/subject. This enables readers to get a good sense of an idea quickly.
Right now, to get a good sense of an idea on Veritula, a user often has to study a branching discussion, which can take a lot of work depending on how the discussion played out. A discussion also emphasises things that were relevant to the disagreements that took place in the discussion, rather than distilling the most important elements of an idea into a hierarchy, regardless of disagreements that took place in getting to it (like an encyclopedia entry does).
Top-level ideas in a discussion thread are not standalone pages.
Every idea (including every top-level one) has a separate, linkable page. You can reach it by clicking the link starting with the # sign.
These are not standalone pages in the sense that a Wikipedia page is a standalone page.
Articles would have the same ‘page’ status as the discussion pages that currently exist. (Forgive my lack of technical vocabulary.)
A possible counter-factual that may or may not be relevant to the goals of Veritula: An article with title metadata ‘Boron’ would presumably be much more search engine-friendly than a top-level ideas for Boron where the metadata title is ‘#[ID]’ and the actual desired title is merely included as the first line of the body text, while it is effectively a subpage of a discussion of another name.
As far as search engines are concerned, every idea page is already a standalone page. Not an SEO expert but I cannot imagine search engines penalize URLs containing an ID.
‘page’ status
What is a page status? How did you determine that an idea’s page status is not the same as a Wikipedia article’s?
Right now, to get a good sense of an idea on Veritula, a user often has to study a branching discussion, which can take a lot of work depending on how the discussion played out.
While this is true for most existing discussions, it’s not a fundamental limitation of discussions in general. For example, ‘How Does Veritula Work?’ has several long-form posts without much discussion. It just depends on what kinds of posts people want to submit.
See #2777.
While it is true that discussions don’t restrict people from posting long-form content like what is on the ‘How Does Veritula Work?’ discussion, that is not the intuitive function of a discussion thread. I believe the long-form content in that discussion is much more natural to an article format.
I think it is worth noting that I am much more excited to publish standalone articles than to drop top-level ideas into discussion topics.
I am not marking this as a criticism, as my personal desires in this respect may be irrelevant to the goals of Veritula.
Top-level ideas need to be published to a specific discussion, which will cause some amount of silo-ing or similar dynamics.
Didn’t you want competing articles on some topic? In which case the same criticism applies to articles as well, unless I’m missing something.
I used to think that articles would need to be grouped in some way, but I no longer think so. Articles will often compete, even if they aren’t about the same or even similar topic.
E.g. an article ‘Easy-to-Vary Explanations’ would compete with an article ‘The Simulation Hypothesis’
Users would be able to point out and connect conflicting articles, but that wouldn’t cause them to be connected by topic, but rather by conflict.
I think so. If Veritula did implement articles, the first thing I’d want is the ability to criticize them; to submit deeply nested counter-criticisms; and to render a label showing how many pending criticisms an article has, calculated based on criticism chains. Which is just what Veritula has already.
If Veritula did implement articles, the first thing I’d want is the ability to criticize them; to submit deeply nested counter-criticisms; and to render a label showing how many pending criticisms an article has, calculated based on criticism chains.
I agree, and I think here you have inadvertently pointed at a key difference between discussions and articles. In terms of implementation, articles would be a near clone of discussions, except that the articles themselves can be criticised by users, including all the functionality that articles being criticisable may one day come with, like entire articles going dormant if they don’t answer criticisms within a certain period.
A couple of examples: If I wanted to keep and share information on Karl Popper, it would be a lot more intuitive to produce an article on him in encyclopedia style—where I can present information in a hierarchy, rather than creating a discussion and then making each detail about him a top-level idea, which is more chaotic. The same would be true if I wanted to make articles on CR terms—this doesn’t seem very natural to do in a Veritula discussion, but would be very natural in a series of Veritula articles, one for each term.
It also favours this articles idea that implementing it would be fairly straightforward, due to how much could be carried over from the discussions implementation. It makes it low cost to try.
If I wanted to keep and share information on Karl Popper, it would be a lot more intuitive to produce an article on him in encyclopedia style—where I can present information in a hierarchy, rather than creating a discussion and then making each detail about him a top-level idea, which is more chaotic. The same would be true if I wanted to make articles on CR terms—this doesn’t seem very natural to do in a Veritula discussion, but would be very natural in a series of Veritula articles, one for each term.
Just because something feels unintuitive or unnatural to you doesn’t mean it isn’t the right way for it to be done in the grand scheme of things.
If a goal of Veritula is for it to eventually be widely used, it should cater to at least some of what people are used to. The articles and encyclopedia formats are the most standard way for high-level information to be presented in written form, and internet users expect different kinds of content in articles vs discussions.
If I wanted to keep and share information on Karl Popper, it would be a lot more intuitive to produce an article on him in encyclopedia style—where I can present information in a hierarchy, rather than creating a discussion and then making each detail about him a top-level idea, which is more chaotic.
You already don’t have to do divvy it up like that. Nothing is stopping you from creating a discussion called ‘Karl Popper’ and then posting a single, long-form, top-level idea where you present information in a hierarchy.
Since discussions themselves are criticisable, is there anything wrong with just titling a discussion 'Karl Popper' and then putting the equivalent of an encyclopedia article in the about section? That is functionally identical to what an article would be, but I am interested if you would prefer discussions not be used that way.
Note: Discussions with outstanding top-level criticisms do not render a 'criticised' pill like ideas with outstanding criticisms do.
Continuing on from #2882, would it make sense to enable users to criticise the discussion/entry/topic, such that it would render a criticism pill?
… is there anything wrong with just titling a discussion 'Karl Popper' and then putting the equivalent of an encyclopedia article in the about section?
Yes. About sections can’t be part of criticism chains.
… is there anything wrong with just titling a discussion 'Karl Popper' and then putting the equivalent of an encyclopedia article in the about section?
About sections are for context or background info, not content.
I just realised that it is possible to publish a top-level idea as a 'criticism' in a discussion, in the way I have advocated an article would be criticisable. I am struggling to understand what it means to criticise a discussion. @dennis-hackethal may you please explain this?
I am struggling to understand what it means to criticise a discussion.
Top-level criticisms don’t criticize the discussion as a whole. They’re just criticisms of something. Anything. It depends on context.
For example, top-level criticisms in the Veritula – Meta discussion are often bug reports. So they’re criticisms of Veritula.
If ‘discussions’ take on a broader form, like we have discussed up to #2880, would this change? What if a user wishes to express that they take issue with something written in the entry/topic body text? I suppose they would quote it in their top-level criticism.
If ‘discussions’ take on a broader form, like we have discussed up to #2880, would this change?
Maybe. It could depend on which term Veritula adopts.
What if a user wishes to express that they take issue with something written in the entry/topic body text? I suppose they would quote it in their top-level criticism.
Yes.
Maybe about sections should themselves be criticizable… In which case they’re just regular top-level ideas. So maybe I could just remove about sections for future discussions. I’ll mull it over.
Forget the term ‘article’ for a second. It sounds like you want the ability to post ideas without having to associate them with a discussion, is that right?
What if somebody wanted to post something related that isn’t a comment or criticism? Where/how would they do that?
The user could publish it as a separate independent idea, including a link to the idea they want to relate/refer to.
This is how relating discussions works currently. For instance, if I start a discussion on Bitcoin, I might want to connect it to the existing discussion on Zcash. At present, the only way to achieve this is by adding a link to the Zcash discussion within my new Bitcoin discussion.
I suspect you would agree with me that this approach to how discussions interact isn’t really an issue. I also think it wouldn’t be an issue for independently published ideas, for the same reasons.
Note: This has led me to the idea that links within Veritula could be bidirectional. Each idea could have an option to display all other ideas that refer to it. I will submit this as a top-level idea in this thread.
The user could publish it as a separate independent idea, including a link to the idea they want to relate/refer to.
Posting a sibling on an existing discussion is far easier.
Interview published today, with one of the founders of Wikipedia:
https://youtu.be/8-0vUZ0hTK4
He argues, like I do, that Wikipedia should allow multiple competing articles on each topic.
I partly agree with him on other problems he identifies, but unfortunately he doesn’t come at it from a Popperian angle.
I still think that Veritula already offers what you want – posting a single, top-level idea that is structured any way you like, to a new discussion whose title can be as open-ended as you like – but I’m sympathetic to your motivation.
Not every user is always interested in starting a discussion. Maybe they just want to put some information out there. And although others should still be able to discuss that information, criticism chains and all, that may not always be their primary motivation for posting the information in the first place.
So I’m open to replacing the word ‘discussion’ with a more general word. It should still communicate a sort of ‘grouping’ of ideas but need not be as narrow as ‘discussion’. Would that help?
ChatGPT suggestions:
Topic, thread, subject, space, entry, note / post / piece, context, cluster.
It’s also worth considering what each word would sound like in terms of UI elements. For example, ‘Start a new topic’, ‘Share a space’, etc.
So I’m open to replacing the word ‘discussion’ with a more general word. It should still communicate a sort of ‘grouping’ of ideas but need not be as narrow as ‘discussion’. Would that help?
Certainly. I think this makes a lot sense.
I think ‘entry’ is my favourite of the ones you mentioned (and of some others I explored with Gemini). ‘Topic’ is also alright, but seems more leading than ‘entry’. I like ‘entry’ because it seems the most agnostic to user intent, while also working fine with UI elements.
I noticed that the idea count of some discussions in the Discussions page seem to be inaccurate. In the Keeping Tidy discussion, I count 13 ideas, including revisions, while the listing for it on Discussions says it contains 17.
You forgot to count comments on older versions of ideas.
Since users are able to revise other users’ ideas, why is it standard practice on Veritula to submit trivial improvements to ideas (such as correction of typos, poor grammar and redundancies) as criticisms, rather than directly revising the idea itself? Example: #2865
Perhaps I have misunderstood the intention of enabling users to revise other people’s ideas.
There are a few reasons people might send criticisms instead of revising an idea themselves:
- You get a chance to disagree.
- Submitting a criticism is easier.
- A criticism is a written record explaining why a revision is necessary.
Because of the third reason, you may see people post a criticism and then immediately revise your idea to address it.
Maybe I’m wrong but I’m sensing a bit of frustration between the lines. Please note that Veritula pursues a higher standard of error correction than other platforms. Some criticisms may be unexpected; discussions could go in a direction you did not anticipate. You may receive criticisms that would be deemed nitpicky on other platforms, but they’re not meant to be. They may go beyond what’s strictly socially acceptable. I intend criticism to be a gift to you. For ‘small’ criticisms, it’s usually best to revise accordingly and not counter-criticize.
Your idea reads more like a question than a criticism. But since I’ve (hopefully) answered it, I’m marking this response a criticism to neutralize it.
Thank you for clarifying this. The idea of submitting a criticism and also immediately revising makes sense.
The criticisms you shared today (that inspired me to post #2884) are valid. This question came out of confusion as to how Veritula is intended to be used, rather than frustration directed at you.
Bug: as you cycle through a parent’s versions on ideas#show, the children are suddenly not being filtered anymore, and the highlighted idea suddenly has siblings.
Fixed as of 27123bd.
Please add a ‘first, previous, next, last’ navigation thing to the top of the activity feed page and similar pages. Currently I need to scroll to the bottom to go to a different page.
Good call. I made the pagination ‘sticky’ as of 1e7a85d. Archiving this but let me know if something isn’t working right.
Obsidian autopairs markdown syntax and brackets. I like it a lot and would like Veritula to have something similar!
I haven’t used Obsidian, so I don’t understand what you are requesting. Is it that, whenever you open a bracket, you want the closing bracket to appear automatically?
I’ve asked Gemini to explain it:
1. Auto-Closure (Insertion State)
When the user inputs an opening delimiter, the system immediately injects the corresponding closing delimiter and places the caret (cursor) between them.
Input: (
Buffer State: (|)
Logic: insert(opening_char) + insert(closing_char) + move_caret(-1)
2. Type-Through (Escape State)
If the caret is positioned immediately before a closing delimiter that was autopaired, and the user types that specific closing delimiter, the system suppresses the character insertion and instead advances the caret.
Context: [text|]
Input: ]
Buffer State: [text]| (Not [text]])
Logic: if (next_char == input_char) { move_caret(+1); prevent_default(); }
3. Atomic Deletion (Regression State)
If the caret is between an empty pair of delimiters, a backspace event deletes both the opening and closing characters simultaneously, returning the buffer to the pre-insertion state.
Context: (|)
Input: Backspace
Buffer State: |
Logic: if (prev_char == open && next_char == close) { delete_range(caret-1, caret+1); }
4. Selection Wrapping (Transformation State)
If a text range is selected (highlighted) and an opening delimiter is typed, the system wraps the selection rather than replacing it.
Context: |selected_text|
Input: [[
Buffer State: [[selected_text]]
Logic: surround_selection(input_pair)
5. Markdown-Specific Heuristics
Obsidian applies context-aware logic for Markdown syntax (e.g., * or _). It often checks word boundaries to determine if the user intends to bold/italicize or use a bullet point.
Context (Start of line): | + * + Space -> Bullet list (autopair disabled/consumed by formatting).
Context (Middle of line): word | + * -> word *|* (autopair enabled for italics).
I have implemented 1-4. Give it a try. I think 5 is out of scope for now but I may revisit it at some point. If auto-closing asterisks are a problem at the start of a line (when making lists), use a hyphen instead.
I can take this opportunity to replace manual markdown with a proper text editor. Then there’s no need for autopaired brackets.
The editor will need to support:
- Automatic links to ideas like #123
- Links to @mentions like @dennis-hackethal
- Safe link formatting
- Disabling of turbo links
- Namespaced footnotes
- Custom blockquote format
- Protection against XSS
- Retention of formatting when pasting
On second thought, implementing a proper text editor would take more work than I initially realized, and is far beyond the scope of what Benjamin is requesting anyway. I can revisit this idea later.
It would be nice if I could collapse the 'submit top-level idea' form. It currently takes up a third of my screen when I scroll on PC.
As of 9087189, the footer automatically hides and shows based on scrolling behavior.
Try it out and let me know if this doesn’t help.
Benjamin suggests making it clearer that you can use Veritula by yourself.
There’s an encoding bug affecting title previews.