tangjeff0

I can remember two questions from Michael Seibel:

1) He asked something about if I was going to find a co-founder or not. I think I said that we started getting traction pretty fast without one and I wasn't going to wait for a co-founder to appear -- cofounders are not something to force. I think this is how he observed that I was "young and hungry." 2) He asked about why I thought open-source was a key differentiator. I said it wasn't, it was just good marketing, and thought you can build the best product without being open-source. I think this turned out to be true. Some arguments for open-source are that it is better for extensibility, privacy, and community. Obsidian does a great job of these 3 things, arguably the best in the networked note-taking app category, despite being closed-source.

I remember both of these questions actually causing Michael and the other partners on the call to pause and think about what I said, because it wasn't necessarily what they expected. Expected answers to these questions might be: "I'm looking for a co-founder" and "Open-source is better because X/Y/Z" given that I had marketed Athens as "open-source Roam" for the first 1 year and throughout YC.

I thought I bombed the interview because I remember being pretty shocked and speechless when they gave me a call saying I got in.

See my comment to @Syrusakbary

When I asked some of my partners what it was about me/my application that got us in, this is what I heard:

1. We had revenue, meaning we weren't afraid to charge. Many first founders are afraid of charging, and there is step-wise more validation having $100/month than $0.

2. We had a product that my partners could actually download and use.

3. "You seemed young and hungry. And I like young and hungry." - Michael Seibel

Unfortunately, I don't have the video of how our actual interview went. I think that would've been very informative too.

That's right! We made a bet on collaboration because everyone was already doing single player.

Now there are even more single-player tools, they are all still competing with each other, and implementing the same features, i.e. wrappers around GPT-3. Super happy with the bet we made :)

Updated the end of post:

Shout out to Syrus Akbury (W19), Ian Tien (S12), and Taariq Lewis (S15) for encouraging me to apply and helping me with my application way back when :)

But seriously, thank you so much Syrus! I was thinking about you 3 the whole time while I wrote the post, hoping it would help someone else like how you helped me!

This was my first application to YC.

Amazing work!

Thank Ben :)

Also confused here. Slide 7 [0] says seed funding of $1.8M, but Airbyte is also calling the most recent round a $5M seed. Implies they will call the first round Pre-Seed retroactively, rather than calling the second round Seed+. It's all grey at this stage either way!

[0] https://airbyte.io/articles/our-story/the-deck-we-used-to-ra...

Hey! Founder of Athens here, we just launched on HN 2 weeks ago: https://news.ycombinator.com/item?id=26316793

Agree with your comment. What we've found is that most people don't actually want to self-host, even technical users who can. But they all want the optionality to self-host, which you don't have with most SaaS's like Notion or Roam. This is doubley important for "second brains", apps where you brain dump your closest thoughts.

As Balaji has said, given the choice, "you'd always pick open source over a comparable proprietary equivalent."

https://twitter.com/balajis/status/1365212646945923074

True. Roam Extensions have been poorly managed so far, making it extremely difficult for extension developers to develop and maintain. Maybe that'll change, but an open platform is generally better for innovation.

Another use case that goes beyond individual notetaking is collaborative knowledge management for organizations. So far Roam's collaborative features have been lacking to say the least.

So basically a Github vs Gitlab scenario. Both are extremely valuable companies. One is more for individuals, the other for enterprises. Knowledge management can go broad and deep, and we're only processing and collecting more information. Never underestimate a growing problem/market.

Yup, still thinking about pricing and features. Working on the privacy policy and ToS this week.

This is my first time hearing of Sandstorm!

Their page https://sandstorm.io/how-it-works writes:

For example, when using Etherpad – a document editor app – on Sandstorm, every document lives in a separate container, isolated from the others. The front-end and database for that document live in the container. The container has a private filesystem for storage. JavaScript running in the user’s browser can talk only to the document container for which it was loaded, no others. All of this makes up a single “grain”.

Right now Athens works directly with the filesystem (and therefore filesync services), not a REST-ful/HTTP server. I'm not sure how Sandstorm apps "talk to the document container." If they allow read/write access to the filesystem from the web app, it could work, but I'm not sure how Sandstorm works.

Very curious, can you elaborate on these principles? i.e. academic design vs SaaS?

https://twitter.com/flancian is working on a generic tech that would bridge notetaking apps together. The important syntax we all agree on is [[wikilinks]] and some subset of markdown, but anything beyond that would require pretty close coordination.

I do wonder if additional features are added, especially those that are not plain-text, how they would be supported. Even markdown-based notetakings struggle with block refs.

The first time I used Tiddly years ago, the UX never resonated with me so I wasn't able to get over the learning curve.

More recently, one of our users gave me a pretty detailed tour of their Tiddly, which shares sentiments of the other commenters. Single file is great until it's not. Lots of plugins but requires manual config. Needing to startup a server to collaborate wasn't great.

What "killer features" do you think Tiddly has?

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!

* 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.

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).

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!

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

Simplicity wins. Pencil and paper FTW

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.

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

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.

More improvements coming soon. Checkout a demo of one our contributors work in progress enhancement: https://www.loom.com/share/6ea7c016d535469fbc036218d54e4538

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.

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

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.

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.