[HN Gopher] Launch HN: Athens Research (YC W21) - Open-Source Ro...
___________________________________________________________________
Launch HN: Athens Research (YC W21) - Open-Source Roam Research
Hi Hacker News! My name is Jeff Tang and I'm the founder of Athens
Research. Athens is an open-source and local-first alternative to
Roam Research. Roam Research is a notetaking application, and what
they really got right was the "bidirectional link." The problem
with notetaking is that we don't look back at 99% of our notes.
Organization systems like PARA, BASB, and GTD can extend the shelf-
life of information, but they're mechanical and tedious to
maintain. On the other hand, without a system, we just hope that
search will one day have the answers. What comes after search,
tags, and folders? With bidirectional links, you never have to
worry about where you write a note. Bidirectional links allow you
to connect any two notes together, creating a knowledge graph.
Structure emerges organically, bottom-up. This way of joining any
arbitrary entities together is a paradigm shift (sorry to be
cliche). The graph-based approach subverts the tree-based hierarchy
most notetaking apps (and most applications/OSes/computer systems)
have used until now. This is fundamental because hyperlinks are
primitives, used by every single internet user. Just imagine using
computers and phones without links! This is why Athens is about
more than just notetaking. I believe networked applications with
bidirectional links and data could become a new category itself.
Of course, this bidirectional idea isn't new. In fact, it goes as
far back as the origin of the Web. It's the original concept of
hypertext and Xanadu, which Ted Nelson has been advocating for
decades. More recently, aspects of it were attempted by the
Semantic Web. Yet the adoption never really caught on, until
perhaps now. Something else that's interesting about the most
powerful networked tools like Roam and Athens is that you can't
really make these apps with JavaScript or plaintext/markdown. For
maximum power, you want a true graph database. Both Roam and Athens
leverage a front-end graph database called DataScript, which is
written in Clojure(Script). JavaScript doesn't have a native
analog, and Neo4j is only server-side. This matters because I
believe this is the first consumer use case for graph databases. I
believe both Roam and Athens are general-purpose platforms where
individuals and organizations can centralize all of their knowledge
and tasks. I believe the graph is the right data structure to do
this with. More broadly, I believe networked applications beyond
just notetaking can emerge. These networked applications can
develop unique interactions and patterns in-app. They will even be
able to share data between one another--Datascript has a native
interface for querying multiple databases at once--unlocking new
ways for users to synthesize, analyze, and transform their data at
scale. I started working on Athens in March of 2020 after
interviewing at Roam Research. At the time, I was certain Roam was
going to change the world with their vision of networked thought.
Pre-Roam, I was a power user of Notion, even giving a Notion
productivity workshop to my friends (where I actually mention Roam
https://youtu.be/4HXHk5C3bSc?t=5820). But it was clear to me that
Roam was doing something different from Notion altogether, on the
graph. It was clear to me that this was about more than just
another productivity app. Unfortunately, I had a glaring lack of
Clojure experience. It didn't seem like I was going to get a call
back from Roam, so I saw two options going forward. Option one was
to find other applications of graphs and bidirectionality. I saw an
opportunity in messaging to develop a "Slack Killer." Chat is
another place where information was constantly getting lost in
streams and siloed channels. Option two was to develop an open-
source version of Roam. I wanted to prove I could learn Clojure
fast (and hopefully get a return call from Roam). After prototyping
these two options for about a week, I tweeted them to the
#roamcult:
https://twitter.com/tangjeff0/status/1248060649344831488. People
started contributing and a community started forming. Designers,
PMs, and even veteran Clojurians began contributing. Assuming the
graph database and bidirectional links are important to the future
of computing, then why take an open-source approach? The primary
answer is about privacy, longevity, and ownership. Users should
have local-first control over their thoughts and their "second
brains." Right now, if AWS's servers go down, Notion goes down,
which has happened multiple times this year. Roam has notably
suffered from downtime and data loss. Local-first and open-source,
any version of Athens will always be locally usable, buildable, and
modifiable for the rest of time, regardless if Athens the company
goes under. User data will first and foremost always be owned by
users. Another reason is that open-source is an effective
development process, at least in our case. In less than a year of
development, with essentially zero spending, Athens has created a
"good enough" alternative to a closed-source product that took 3+
years to make. It's not because I'm a "10x engineer." It's exactly
the opposite! Athens was built by dozens of engineers and designers
who built and designed things in a way I never could (largely in
their free time). We've had feedback and input from users from day
one, directly in the channels we do work in. Not only do the best
ideas rise to the top, they can be directly integrated into the
source code, improving the experience of all users. As for how we
will make money, most users, even technical ones who could self-
host, don't want to self-host (but they value that optionality and
insurance against lock-in). They want a subscription SaaS, which
will make features like backups, integrations, and collaboration
much easier. For enterprises that do want to self-host on-premises,
we can provide additional support and security features, similar to
Mattermost or GitLab. Our first enterprise user is an a16z-backed
crypto startup. You can sign-up for our SaaS or enterprise packages
through our Open Collective: https://opencollective.com/athens.
What are your thoughts? If you're optimistic and you use Roam,
Athens or another networked notetaking app, what are you most
excited about for 10-20 years in the future? Or maybe you're
skeptical and you think networked apps and bidirectionality will
flame out like Xanadu and the Semantic Web. I'm guessing there will
be questions about open-source too, particularly around paying
contributors for their work. I'm all ears!
Author : tangjeff0
Score : 208 points
Date : 2021-03-02 16:11 UTC (6 hours ago)
| ducktective wrote:
| Very interesting! Good luck!
|
| 1- Why did you choose Clojure?
|
| 2- Last I checked, Roam founder here on HN said something along
| the lines that "the self-host functionality is on their
| minds"...this was around late 2019 I think. Wonder what's the
| update on that...
|
| 3- Actually, personally if I want to use this approach, I
| definitely want to self-host. Wonder what would happen to the
| data if this tool gets updated. Is it just markdown + some syntax
| for bidi links?
| tangjeff0 wrote:
| 1- I cover this in the post:
|
| > Something else that's interesting about the most powerful
| networked tools like Roam and Athens is that you can't really
| make these apps with JavaScript or plaintext/markdown. For
| maximum power, you want a true graph database. Both Roam and
| Athens leverage a front-end graph database called DataScript,
| which is written in Clojure(Script). JavaScript doesn't have a
| native analog, and Neo4j is only server-side.
|
| 3-Yes, we've already updated the database before within the
| application. DataScript makes it quite easy to update the
| schema.
| ipsum2 wrote:
| Have you benchmarked this? I don't think a lifetimes worth of
| notes (maybe 10,000+ documents?) will slow down sqlite, even
| with many interconnecting nodes.
| tangjeff0 wrote:
| I haven't yet! I'm sure some Roam DB's are over 10k
| documents. If Datascript-based applications can get past
| the initial load time with better client-side caching,
| performance will always be better. "Local-first" apps could
| become their own new category. I recommend reading
| https://www.inkandswitch.com/local-first.html
| code-anth wrote:
| This is great, congrats. While I was waiting for this though, I
| ended up learning emacs, org-mode, and org-roam. Not sure if I
| wanna change now. Emacs can do all of this already, right?
| tangjeff0 wrote:
| Emacs/org-mode is pretty optimized for singleplayer, technical
| users, and plain-text. Further down the road, we hope to
| support APIs/integrations, collaboration, and rich media, and
| service the less technical user!
| rronalddas wrote:
| Is it something like Obsidian (https://obsidian.md/) but with
| more than just markdown files?
| raun1 wrote:
| It's closer to Roam Research, the project that inspired and
| catalyzed Obsidian.md
|
| There are a few major differences, but otherwise, the
| functionality is mostly similar.
| nynx wrote:
| This is great stuff, Jeff. I sponsored athens for a while--
| stopped after you got funded by YC--but I'm still glad things are
| going well.
|
| Now that there are a couple of apps that are doing this _kind_ of
| thing, I think it might be time to start looking at whether bi-
| directional links could be a W3 standard in some way (i.e. a
| standard bidirectional link metadata endpoint). It 'd be awesome
| to bi-directionally link across from athens/roam to github to
| matrix.
|
| Perhaps the concepts need a few more years to bubble and mix a
| little, but start thinking about how this could work.
| Off wrote:
| Hi Jeff! Great to see a Roam alternative backed by YC! Congrats
| on the launch!
|
| What are you thoughts on the other Roam alternative, Logseq[1]?
| It seems to be doing really well and has a lot of features, from
| github sync and encrypted data to custom themes and publishing,
| it looks like privacy is their main goal, while being local-first
| and opensource, do you think that such features will be
| implemented in the near future and will those features become
| somewhat a standard across PKM's?
|
| Good luck with the launch!
|
| [1] https://logseq.com
| yewenjie wrote:
| I really am looking forward to Logseq maturing since it offers
| `org-mode` markup support and can potentially inter-operate
| with `org-roam`. :)
| lancesells wrote:
| I don't want to sound too harsh here but I had a loading screen
| come up to show me a page of text. I know it's not plain text
| and probably has some giant javascript framework behind it but
| still a loading screen for that page?
| pps wrote:
| This is not a webpage, but fully functional web app (you can
| edit that text). That text is stored as plain text, then
| parsed and moved to DataScript (in-memory clojurescript
| database). That's why you see loading screen. This happens
| only when you reload tab, otherwise there are no loading
| screens when one is working within this app (it also has a
| desktop app [electron]).
| tangjeff0 wrote:
| LogSeq is great, tried collaborating with them a while ago,
| starting with a shared spec, but it didn't work out. How much
| of this is standard is up to the tool makers!
|
| All features are possible, especially given similar
| technologies. The question is about design/product - whether we
| _need_ to have all these features. Most notetaking apps are too
| bloated IMO.
| rrampage wrote:
| Congrats on the launch! Are there any good resources for using
| Athens as a Zettelkasten in the lines of [0] or [1]?
|
| [0] - https://www.roambrain.com/implementing-zettelkasten-in-
| roam/
|
| [1] - https://medium.com/@anthonyclemons1/roam-research-the-
| digita...
| tangjeff0 wrote:
| Would be great to have a canonical resource like that. For now,
| I'd just read the Roam resources that use block refs and
| bidirectional links apply or ask in our Discord!
|
| We actually have people doing a live workshop right now on
| workflows for Athens in our Discord!
| gw wrote:
| Y'all both are making great tools but consider giving a read-only
| view of the page when javascript is disabled. After disabling JS
| this gives me a blank white screen:
| https://athensresearch.github.io/athens/ Same thing when i tried
| it with roam.
| Fractal_HQ wrote:
| Considering the page you linked is a javascript application,
| why would anyone expect to be able to use a Javascript
| application without Javascript?
| gw wrote:
| Is it a "javascript application" or a "page with text that
| uses javascript for dynamic features"...
| 0xferruccio wrote:
| This is amazing, the thing that scares me the most about Roam is
| that I wouldn't be able to export data. Also like Notion it gets
| extremely slow very quickly.
|
| Hope that this local first solution will make you avoid the
| performance problems those apps have
| abalaji wrote:
| You can definitely export your data from Roam. Maybe not some
| types of data, such as images, but you can scrape that if you
| needed to. I can say this for certain as someone who's worked
| on open source import, export, and backup tools for roam. [1,
| 2]
|
| [1] https://github.com/MatthieuBizien/roam-to-git
|
| [2] https://github.com/adithyabsk/keep2roam
| cloverr20 wrote:
| I have been using vimwiki for around a year now, using pandoc to
| convert into html with a simple custom template, stork-search to
| search the files and syncing the collection weekly over to my
| other computer, phone.
|
| I love this setup as there is no internet needed, full text
| search on all the documents and very less friction while starting
| to write something. I have tried other apps like obsidian, roam
| etc but keep coming back to this one due to its simplicity.
| tangjeff0 wrote:
| Simplicity wins. Pencil and paper FTW
| ska wrote:
| Searchability really suffers in paper systems.
| bachmeier wrote:
| Paper systems don't have to be "100% paper". All you need
| is the metadata from your notes. You can give each note a
| number and then add that number plus a couple tags and a
| short description to a spreadsheet. Alternatively, you can
| take a picture of the note and add that to your digital
| system. It's not how I currently do things, but it's
| infinitely better than a primitive digital system where you
| take notes and never touch them again.
| ska wrote:
| Paper systems also suffer from "never touch them again",
| and adding a digital index only provides superficial
| search ability.
|
| I'm not saying paper systems don't have a place - people
| have put them to use for centuries after all. They do
| have very real limitations though, and to be really
| useful require more ongoing work than many people are
| willing to put in, especially if they grow to an
| appreciable size.
| pps wrote:
| Bullet Journals are perfect for that (
| https://bulletjournal.com/pages/book ), I'm still using
| them for managing my personal life (ideas, goals,
| progress on stuff, daily journals, etc). Having knowledge
| base in digital format is better in many ways, but IMO
| nothing beats notebooks when it comes to solving problems
| and thinking.
| cloverr20 wrote:
| The search ability is one thing you will definitely want as
| your collection gets big. I got to know about stork-search
| from a post in hn and it worked very well for me,
| https://stork-search.net/
| ska wrote:
| Yes. Orgmode mostly scratches this itch for me and has
| graph-of-notes rather than tree-of-notes already, and is
| reasonably futureproof.
| lrae wrote:
| > In order to opt-out of analytics, please become a User or
| Sponsor through OpenCollective.
|
| Interesting way to monetize, not sure how I feel about that, but
| it would be nice if you'd at least list what data you are
| collecting (or link to your privacy policy/faq/what ever.)
| lvh wrote:
| Hey! This looks super cool. The desktop app seems fairly
| explicitly single-user (looks like 1 big transit file). Do you
| have any opinions on using these tools in general and Athens in
| specific to do knowledge sharing among teams? (I would imagine
| that needs some kind of transaction log, mostly hoping
| transactions commute and maybe stacking the deck with something
| like Pijul.)
|
| Is the answer "host it as a web service" (and corollary "let us
| do it for you")?
| tangjeff0 wrote:
| Using a filesync service such as Dropbox, you can sync state
| across multiple clients. We have a commercial user doing this.
| The single transit file won't scale however, so we've started
| working on a transaction log just as you said. Want to make
| sure it's pretty robust before deploying, however, as no data
| loss is the first priority!
| https://github.com/athensresearch/athens/pull/624
|
| To your second answer, yes and yes. I write in the post:
|
| > As for how we will make money, most users, even technical
| ones who could self-host, don't want to self-host (but they
| value that optionality and insurance against lock-in). They
| want a subscription SaaS, which will make features like
| backups, integrations, and collaboration much easier.
| ryukafalz wrote:
| > The single transit file won't scale however, so we've
| started working on a transaction log just as you said.
|
| Would it be possible to deploy a web-based instance with the
| server handling storage and collaboration? If so, I might try
| my hand at packaging it for Sandstorm once that's available.
| Would make self-hosting Athens super easy for Sandstorm
| users.
| aantix wrote:
| Don't we see the bidirectional linking all the time?
|
| Jira, Github issues/pull requests, all list the linkage from both
| sides?
| glifchits wrote:
| Those are examples of why it is so incredible. To have it in
| your notes application as seamlessly as Roam does it is a game
| changer for notes.
| AriseAndPass wrote:
| I use Roam, and I've had my eye on your project for many months
| now, so I'm super excited to see you come so far. I'm also
| passionate about privacy and having control over my data - IIRC
| the way Roam handles image uploads is by uploading the image to
| firebase and giving you a link that anyone can use to view your
| image, with no way to delete that image, so you just have to
| trust in the 'unlisted' nature of the link. Not a big fan of
| this.
|
| One thing I think was missing when I last looked at Athens was a
| working high-fidelity import of a Roam EDN export - without this
| I can't see an easy way to migrate, and I'm guessing there are
| other Roam users in the same boat? I'm sure it'll come along,
| until then I'll sit tight in anticipation :)
| tangjeff0 wrote:
| EDN import is done, just want to improve performance in Athens
| as most Roam dbs are bigger. I know Roam users will have higher
| expectations :)
|
| https://github.com/athensresearch/athens/pull/561
| AriseAndPass wrote:
| !! the day has come :)
| bronlund wrote:
| So all I can do in that graph view, is moving nodes around? Am I
| missing something? Like, is there any way to jump to the actual
| note from there?
| tangjeff0 wrote:
| More improvements coming soon. Checkout a demo of one our
| contributors work in progress enhancement:
| https://www.loom.com/share/6ea7c016d535469fbc036218d54e4538
| helloguillecl wrote:
| This is amazing. I like Roam Research but I refuse to give full
| control of something so important to _any_ third party. At this
| point we have all experienced what it is like to give the control
| over your digital life to FAANG-like entities with priorities
| other than their own users well-being. We can and should ask for
| better.
|
| If it will be my second brain (please note how important this
| sounds), what I want is to be able to be in full control of the
| data I generated with it.
|
| I'd happily pay for an Open Source SaaS service from which I can
| download my data and use it in my own computer/server if I wish
| to do so, much like Sentry or Strapi.
|
| Edit: Clarity, grammar and spelling
| Graziano_M wrote:
| Roam has plans for offline-only storage.
| lrae wrote:
| Is that out of beta and working now? Also is it still only
| available in the $500 (?) dollar plan or what ever it was?
| Graziano_M wrote:
| Nope and yes!
|
| I am just pointing out that closed source doesn't
| necessarily mean 'not in control of your data'.
| lrae wrote:
| True. And too bad, would give it a try again otherwise.
| tern wrote:
| I'm currently using NotePlan because I haven't been able to find
| a good Roam-like iOS app. Is this on your radar?
| tangjeff0 wrote:
| We mention mobile on our OpenCollective in our OSS Sponsor
| plan. Plan to have a great mobile experience, which most
| notetaking apps are not great at.
| https://opencollective.com/athens/contribute/open-source-spo...
|
| Hopefully will have a great roadmap too like Gitlab's:
| https://about.gitlab.com/direction/maturity/
| mmmkkaaayy wrote:
| Could you please share some of your experience/plans regarding
| implementing cross-device sync?
|
| eg:
|
| * Which db is the source of truth?
|
| * How will conflicts from offline editing be handled?
|
| * Will you be able to see edits made in realtime across the
| devices?
| tangjeff0 wrote:
| * Currently `index.transit` is the source of truth. When a user
| sees new changes, their current db is saved, and they have the
| option of opening the new one or continuing to edit the current
| version. The entire history of the db is saved right now
| (`{timestamp}-username.index.transit.bkp`) while we work on
| better conflict resolution and merging. * Don't have conflict
| resolution yet for offline editing. * We plan to make a
| websocket server for some the real-time UX.
| lquist wrote:
| Honest question: Why use academic design principles instead of
| SaaS design principles?
| junipertea wrote:
| I use obsidian right now. I do enjoy the convenience of markdown
| files, do you have any specific use case where the graph DB would
| be superior to them? Would it stop scaling at very large notes?
| Furthermore, the biggest painpoint for me is sync and cross-
| platform support. I have to use dayone, a journal app on iOS,
| because the experience (of actually writing thoughts) of any
| other app is just too inconvenient for rigorous daily usage.
| solarkraft wrote:
| This is amazing. Until very recently the only tree structure
| "outliners" I found somewhat viable were Workflowy, Dynalist,
| Roam and Transno, all of which are proprietary.
|
| Logseq eventually added an open source option, but that it fails
| to keep sub trees collapsed pretty much kills it.
|
| My current favorite note applications are Dynalist and Workflowy,
| but during my use I have always had a bad stomach feeling about
| privacy, inability to use it for work related stuff and always
| thought "this needs some features breaking out of the tree
| structure".
|
| I'm not entirely sure Athens is trying to be exactly what I'm
| thinking of here, but getting competition in the space is great.
| nextos wrote:
| I'm wondering how much of this can be implemented as a simple
| CLI tool that rebuilds a document graph by looking into a
| directory full of Markdown or Org notes. Ripgrep is certainly
| fast enough to perform search like that, without any index.
| That's how some Zettelkasten-like addons perform search on top
| of an Org directory.
| lambduhh wrote:
| Awesome!
| sandGorgon wrote:
| This is pretty cool! I do urge you to take your domain name
| versus https://athensresearch.github.io/athens/
|
| Could you talk about the clojure part of it? how instrumental was
| it to build Athens Research. could you have built it on Electron
| + Typescript for example
| tangjeff0 wrote:
| We have athensresearch.org and athens-research.com, neither of
| which I love.
|
| We actually do use Electron! ClojureScript compiles to JS at
| the end of the day.
|
| Ultimately Clojure is pretty necessary to use our database,
| Datascript, a graph db with its own data query language,
| Datalog. Datalog is a descendant of prolog, and makes
| recursive/reverse queries trivially easy.
| dmytton wrote:
| Link: https://github.com/athensresearch/athens
| jolux wrote:
| > For maximum power, you want a true graph database.
|
| Do you have empirical validation of this claim? Anecdotally,
| Postgres has a pretty rich set of graph modeling features these
| days, and keeps getting more of them, and SQL databases are often
| operationally simpler than graph databases. Maybe this matters
| less in a client side app?
| tangjeff0 wrote:
| It's _possible_ to model graphs in Postgres, but it 's a lot
| more complex. This video compares two queries, one in SQL, and
| one in Datalog (the query language DataScript uses)[0]. We
| should probably model a knowledge graph with a graph database!
|
| SQL databases are indeed operationally simpler but that's
| because they have been around for much longer and are more
| battle-tested.
|
| [0]: https://youtu.be/tV4pHW_WOrY?t=1772
| jolux wrote:
| > We should probably model a knowledge graph with a graph
| database!
|
| I realize this seems intuitive, but the relational model has
| proven itself to be surprisingly flexible in its ability to
| store multiple different data models efficiently. Similar
| arguments were made about the suitability of document stores
| to social networking websites ten years ago, and I think we
| know how that panned out.
|
| > SQL databases are indeed operationally simpler but that's
| because they have been around for much longer and are more
| battle-tested.
|
| I wouldn't discount the age and battle-testing, though.
| They're the first choice for data storage for many good
| reasons. Not least of which is the flexibility and power of
| the relational model.
|
| It's clear that graph query languages are more expressive for
| graph databases. What's not clear to me is whether there's
| anything fundamental about that expressiveness, or whether it
| will eventually be replicated in SQL. Have you tried using
| recursive CTEs before?
| tangjeff0 wrote:
| Well the other aspect of it is that DataScript is client-
| side. That said, we could use sqlite in browser or even
| IndexedDB at this point. Yes, a pure JS/TS alternative
| without a graph db implementation is _possible_. But when I
| started, I chose the same language and db to ensure parity
| would always be much more possible.
|
| Haven't tried recursive CTEs before, maybe I should dig
| into it more!
| jolux wrote:
| > Yes, a pure JS/TS alternative without a graph db
| implementation is possible. But when I started, I chose
| the same language and db to ensure parity would always be
| much more possible.
|
| To be clear, I think Datalog and Clojure are both
| actually really cool, I'm just a huge SQL fan too. I
| think the architectural decisions you made in this case
| make perfect sense :)
| fabiospampinato wrote:
| > Something else that's interesting about the most powerful
| networked tools like Roam and Athens is that you can't really
| make these apps with JavaScript
|
| How come? There's no single feature that you can implement in any
| other programming language that you can't also implement with
| JavaScript, right?
| tangjeff0 wrote:
| Have you read PG's essay on Lisp? (Clojure is a dialog of Lisp)
| http://www.paulgraham.com/avg.html
|
| Main reason is access to datascript, one of the only client-
| side graph databases, which doesn't work the same with
| JavaScript.
| vemv wrote:
| I wonder if the quite extremely early/intense competition that
| Roam faced as soon as it was shared publicly will result in
| _none_ of the competitors succeeding (at the very least as a
| viable for-profit company).
|
| It's possible that sometimes we have to let early ideas fully
| succeed to see how the market actually performs. Else one can end
| up in an arms-race situation that ultimately only leads to a tiny
| user base for each company.
| rl3 wrote:
| Things like Roam represent a very _tiny_ fragment of a much
| larger puzzle that 's existed for years prior to their
| existence. From a theoretical perspective, they are only novel
| insofar as they exist as concrete products today.
|
| Sometimes it's healthy when spaces heavily fragment due to
| hypercompetiton. It allows products with strong technical and
| theoretical groundwork to show up later and render the entire
| space effectively obsolete.
| tangjeff0 wrote:
| I suppose that's a function of how large the market can be, and
| how badly it wants to consolidate.
|
| 1. Market: If the pie doesn't grow, you may be right. If,
| however, these become new platforms, with the majority of use
| cases and user value occurring in the future, then there's
| certainly room for many existing players to succeed, and for
| brand new players to. Most people don't even take notes. What
| if knowledge management looks different in 10 years?
|
| 2. Consolidation: Notetaking is pretty singleplayer and
| subjective right now. Until there are "network effects",
| reasons why people would want to purposefully join the same
| network, a lot of it will simply come down to taste. Note:
| network effects does not simply mean real-time collaboration.
| takeiteasyy wrote:
| You're right on here, but don't underestimate the network
| effect of Extensions for Roam.
| diego898 wrote:
| Jeff (@tangjeff), Im sure you're already familiar with
| Tiddlywiki[1]. How does this compare/draw from/improve/etc on
| that?
|
| For those who arent familiar with TW, I encourage you to check it
| out. Its one of the original bi-directional linked, open-sourced,
| graph-based (as revealed with TiddlyMap plugin, though not using
| a graph database) note-taking apps that is completely
| customizable.
|
| It was recently posted and discussed on HN as well [2][3].
|
| [1] https://tiddlywiki.com/ [2]
| https://news.ycombinator.com/item?id=25527581 [3]
| https://hn.algolia.com/?q=tiddlywiki
| randomchars wrote:
| I've tried to use TiddleWiki, and while it's an impressive
| piece of software, it suffers from the same issue many other
| community-run open source software does: it's ugly, and hard to
| use.
|
| Yeah, I get it, there are themes and plugins, but still, all of
| them are ugly.
|
| And that's just the surface, I've had a few deeper complaints
| too.
| junipertea wrote:
| Not him, but I used TW extensively. The problem was the entire
| wiki is in one HTML file (which is impressive), but it did not
| scale with additional image tiddlers. At some point it would
| just not load. There is a separate NodeJS hosted version which
| I ran for a year, but it had memory issues. (Again, probably
| tied to the number of images). I totally get it's mainly for
| notes, but I'm lazy and sometimes I paste snippets from papers
| rather than rewrite them, so it balloons easily.
|
| It's fantastic software, though!
| nishparadox wrote:
| Having tried running the whole stack on my local a few times in
| the past -- which didn't work well at that time -- I'm excited to
| use it now.
|
| One question I have is: how much compatible will it be eventually
| with other tools like Roam/Obsidian/Logseq (when we want to
| import the graphs)?
| etaioinshrdlu wrote:
| Me and some friends have played around with Roam a bit and we are
| baffled by the app. It just does not work well. It is a badly-
| designed, lower performance, glitchy note-taking app. You end up
| staring at its gaudy giant astrolabe loading spinner more often
| than not. We look at it and end up baffled why anyone would pay a
| monthly subscription for it!
| Dyac wrote:
| How do you feel about Workflowy (another YC company) suddenly
| starting to add new features like bidirectional linking,
| transclusion and file embedding functionality?
| tangjeff0 wrote:
| Similar to my belief that a db will win over markdown long-
| term. The features you mention are all easy to reproduce,
| (especially with more open-source examples).
|
| Long-term, open-source is great at building communities around
| a product/project, which is important for this space.
| nsriv wrote:
| Athens has been incredible for me over the past week, as someone
| that has bounced around using Workflowy, Dynalist, and Obsidian.
|
| The great outliner features of the first two, and the backlinking
| and graphing of Obsidian. My only real reservation is that files
| are not in Markdown. Is there a plan to address that, or is a DB
| central to the architecture? Currently using LogSeq because of
| this but eager to switch.
| tangjeff0 wrote:
| Yes! Good import/export functionality is important. Ultimately,
| it would be awesome if there was direct serialization between
| our database and markdown. This would allow seamless "import",
| the same way Obsidian/Foam/Zettlr are directly interchangeable.
| FlashBlaze wrote:
| Did not expect Zettlr to be mentioned here. Currently my go
| to note taking app.
| mattnewport wrote:
| What do you see as the advantages vs. Zettlr? I haven't got
| to a point where perf seems to be an issue that would require
| a real graph database and having your knowledgebase just be a
| collection of markdown files is the ultimate in local first
| no lock-in portability.
| tangjeff0 wrote:
| The current major difference between markdown-based and db-
| based apps is block references. Over time, the difference
| will become significant as knowledge bases grow in size.
|
| CSV -> Excel -> SQL -> Distributed Cloud DBs
|
| Furthermore, our database supports data types, including
| numbers, dates, etc. I don't think any networked notetaking
| app has executed well on tables and non-string types. UX
| for tables is generally not great for markdown.
| sandGorgon wrote:
| Not markdown, but asciidoc has first class support for
| blocks and references/attributes.
|
| - https://docs.asciidoctor.org/asciidoc/latest/macros/int
| er-do...
|
| - https://asciidoc.org/userguide.html#X60
|
| - https://asciidoc.org/userguide.html#X73
| mattnewport wrote:
| I'm not really familiar with Roam as I'm not interested
| in a non open source tool for this type of app (why I am
| more interested in what you're doing). What are block
| references?
|
| I guess I can see perf becoming an issue for a company
| wide knowledge base or a wikipedia type of thing but for
| a personal knowledge base which is my main use case
| currently I'm not clear it's necessary to have a real
| database and the benefits of just a bunch of markdown
| files are more compelling to me right now. Maybe that
| would change if my knowledge base got big enough or my
| needs more complex regarding links and references.
| input_sh wrote:
| The simplest way I can explain block references is the
| ability to link any line in any file to any other line in
| that file or any other.
| pps wrote:
| > The current major difference between markdown-based and
| db-based apps is block references. Over time, the
| difference will become significant as knowledge bases
| grow in size.
|
| That should be true, but so far it is Roam with the
| biggest problems with performance, from 30+ seconds of
| loading each time you load/refresh tab to constant lags
| in normal usage for some users :)
|
| I personally like the most this mixed approach of Logseq
| - app internally uses DataScript, but data is ultimately
| stored in plain files.
| tangjeff0 wrote:
| It's not either or as you mentioned! Plan to have user
| data stored in plain files as well.
|
| Roam's performance suffers mainly on first-load because
| they are server-first, and they load the entire db into
| memory at the beginning (such that it's quite fast
| thereafter).
|
| Once we have true local-first data structures with
| something like https://github.com/replikativ/datahike, we
| could still have fast in-memory, but also fast initial
| load.
| pps wrote:
| > Plan to have user data stored in plain files as well.
|
| That would be cool :)
|
| > such that it's quite fast thereafter
|
| Not always :) I saw that myself and I also see complaints
| on Roam Slack. In my experience it mostly depends on how
| many queries you have on given page, but sometimes it
| lags (long waiting time when switching between pages or
| opening note in sidebar) also with simple, "atomic"
| notes. But they overall struggle with polishing existing
| parts before adding new features, so maybe performance is
| still on its early days in Roam.
|
| Anyway, I wish you good luck with your project :)
| tangjeff0 wrote:
| Ah, very good to know. Don't use Roam too much these days
| ;) Sometimes it's hard to know if their performance
| issues stem from networking (they use Firebase) or just
| client stuff (i.e. datascript and Reagent,
| Clojurescript's React wrapper).
| whimsicalism wrote:
| Wow! I'm glad that more people are in my exact predicament.
|
| I am currently using Obsidian, but would love a markdown-backed
| Workflowy interface that I could switch to if possible.
|
| Perhaps logseq is that app?
| bachmeier wrote:
| A few alternatives in this space:
|
| org-roam https://www.orgroam.com/
|
| tiddlyroam https://tiddlyroam.org/
|
| Dendron https://dendron.so/
|
| Foam https://foambubble.github.io/foam/
|
| Remnote https://www.remnote.io/
|
| Obsidian https://obsidian.md/
|
| logseq https://logseq.com/
|
| Not an expert with them at all. I've never had a desire to dig
| into all their complexity, but some are pretty passionate about
| it.
| pps wrote:
| And a "few" more here https://www.notion.so/Artificial-Brain-
| Networked-with-linear... ;)
| karlicoss wrote:
| My dream would be seamless interoperation between all these
| tools. Would also mean better 'competition', easier to convince
| people to try them, avoiding lock-in in one tool, etc etc.
|
| For some tools it's already possible to interoperate -- for
| them would be nice to have summaries on what are the caveats
| (e.g. would the tool format my whole note base? would it break
| any special syntax imposed by the other tool? etc etc)
| ihinsdale wrote:
| Having passed on backing Roam Research multiple times[1], which
| proved to be a mistake[2], YC now funds a competitor that is
| quite explicitly a clone.
|
| That said, all the best to the Athens Research team.
|
| [1] https://twitter.com/Conaw/status/1229978388787384320?s=20 [2]
| https://www.theinformation.com/articles/a-200-million-seed-v...
___________________________________________________________________
(page generated 2021-03-02 23:01 UTC)