2.0.0-beta Thanksgiving Launch Party

Okay, great. So yeah, today we're here to celebrate the launch of 2.0.0 beta. This is basically our first milestone for CKM, or collaborative knowledge management, and it's a big deal because now we can actually collaborate on a shared graph. There's a lot of personal knowledge graphs, not too many collaborative knowledge graphs, and we're taking a particular focus on that right now. So today we're going to be trying it out, helping you guys get it set up, installed, giving an overview of some of the features. Also having an ask an AMA, ask us anything, and FAQ. Our engineers are all here on how we built this, as it is more than just a backend. It's actually frontend agnostic and backend agnostic, which makes it quite unique and enables some very promising capabilities in the future. And then if there's time after, we could help some of you guys set up your own Athens servers. So Yeah, I think Matei wanted to do the guided installation, and so I'll hand it off to him at this point.

Awesome, thank you, Jeff. And so just as a reminder, I know we've got a lot of chat going on in Zoom. We started a party chat channel, and it's going to be a little bit easier if everyone has Discord. To just keep the chat going in there. That's also going to be a lot easier for me going down the road with when it comes to DMing for the PoAP. I know a couple of people have asked me for that already. So yeah, let's jump into the party chat and I can go ahead and get started here. Oh, I'm gonna go ahead and share my screen. Hey, Jeff, would you mind?

Yeah, awesome.

Yeah.

All right, we've got a whole lot of people here, so this is going to be interesting jumping into the same graph at once. All right, so can everyone see my screen here? You should see the release pages. Is everyone able to see my screen?

Yes. All right.

Cool.

And if everyone else can, uh, can just go ahead and mute their mic, please.

Awesome.

So I'm gonna go ahead and flip this into the party chat. It's gonna be the direct link for everyone to download the 2.0 beta.

All right.

So we have all the release notes that includes pretty much everything that's gone into the 2.0 beta. Some of this was covered in our Twitter announcement and includes some disclaimers on data loss and how we haven't had any. And that's kind of what we're here to test today. So at the very bottom is where we have the assets. And depending on your operating system, we have a bunch of different executable files. So if you're on the Mac M1, you're going to download the ARM64 DMG. If you're on Linux, you can download the AppImage. If you're on regular Mac, it's going to be the DMG. And then of course, for Windows users like myself, you're going to have this EXE right here. So I'm going to go ahead and download this. Awesome. And once you have it downloaded, just go ahead and install. It's going to bring up a— at least on Windows— a little warning that it's protecting your PC, but you can go ahead and expand the details and just run anyways.

Cool.

All right, so just before we jump into actually into the Athens app itself, I just wanted to kind of go over the scope here. So mostly the features that you'll be seeing are going to be somewhat hidden. It's going to feel like this is just kind of a table stakes thing, and that's because it is. But the way that we've built RTC, it's been 6 months in the making, and it's led to some very interesting things like the Athens Protocol. And this is a real server that you can self-host. It's not based on anything like Firebase. And it leads— kind of paves the way for something like—

Exactly.

Interchangeable front ends and back ends, which is something that we've mentioned in our Twitter announcement. And then the rest of the improvements have been on the user experience and user interface side. So we'll go through those and it's going to look very colorful. It's going to be a lot of people. I think we've got nearly 50 people here today. And then the other thing to mention is on data loss. So we haven't had any on this release. But it is beta, so just keep that in mind as you play with this yourself. It's a beta product, so you got to keep that in mind. We do have a dedicated data loss channel in the Discord. So that's going to be in the feedback area below the meeting area. There's a data loss and there's 2.0 beta feedback, and those are the 2 places we're going to mostly collect asynchronous feedback aside from this from this specific session here. Alright, so I'm gonna go ahead and switch my screen here.

Cool.

So is everyone able to see Athens up on my screen?

Yes.

Yeah.

Alright, cool. So for most of you all who haven't actually played with Athens RTC yet, it's going to load you up in your Local instance of Athens, and you should be pretty familiar with this. It's fast, works just as you expect, and nothing super special here. The most interesting piece is going to be adding a new database. So this is we're going to go ahead and in the top left, this is going to be the DB picker. And at the bottom, go ahead and click Add Database and hop on over to Join. I'm gonna go ahead and copy and paste the IP address that we're gonna be using for today's server, and it's gonna be over in the Part A chat channel. And it should read 139.59.166.118. In the future, we'll definitely make this a little bit easier, but for now it's all IP addresses. So that's going to go ahead in the remote address. And you can give this database any name that you'd like. It's only going to be reflected on client side, so it doesn't actually affect the, the name of the server on the server. This is just going to be for you to be able to pick the appropriate database When you have multiple of these shared graphs. So I'm gonna go ahead and call it Turkey Day. Everyone likes turkey, I think. So I'm gonna go ahead and click Join. All right, so it looks like we've already got a bunch of people hopping into the graph. Yeah, all right. So we're just going to give everyone a second to join in. And if you have any questions, go ahead and post them into the party chat. Okay, Cortex said he was not able to connect.

Let's see here.

All right, we got a whole bunch of colors here. There we go. All right, we have a whole bunch of colors popping up here.

Cool.

So let's do a quick double-check here. If everyone can just go ahead and open up their left sidebar and make sure you're on the right version, it should read 2.0.0 Beta 1 at the very bottom right of the left sidebar. And you can also make sure you're on the right server, mostly because you can see a bunch of people Just kind of writing blocks and jumping in. We also have what's called the page presence here, so you can see this long list of people who've already joined. And everyone has pretty much been given a Greek god name to start off with, but the important piece here is making sure you're on the right server. So if you have any problems, go ahead and click copy, dump it into the party chat, and we'll see what's going on there. But everyone should already be on. Hey, Sid, if you could, would you be able to jump into party chat and see if you can help out Cortex here? He's on the M1 Mac. Okay, thank you. Awesome, guys.

Sweet.

So what all these avatars on the right side are, what we call block presence, and this should be pretty familiar if you use other collaborative tools. It kind of looks like confetti here, and I mean, that's pretty awesome. I don't know in what cases we'll have this many people in one place at once. Generally, people will be all spread out across a graph working on different pages. So let's give that a bit of a shot. I'm going to see who is on other pages. All right, so in this page presence toolbar, you can see that most people are on this page, but then Griffin is on a different page. So if everyone goes ahead and opens up the page presence toolbar and follows Griffin, Or Matt, rather. Here's a Bugbusters page. Cool. And now I see a couple of people joining. I'm sorry for my keyboard being so loud. I like the noise. It's therapeutic. So it seems like we've got a bunch of people hopping over. And again, all you have to do is click on either my name Or someone who's on another one of these pages, and you can basically hop on the bus here. So this is a way for anyone to navigate across the graph just by following people around. In the future, we might be able to just bring people to where you are, have that feature built in, and that's something that we're looking forward to. I'm gonna go ahead and jump back to the daily pages here, or actually I'm just going to follow—

let's see, let's follow Sid.

This is on the daily page here.

Awesome.

Cool.

So again, this is, this is a pretty basic look at what you get from real-time collaboration. And the other features that we've added are mostly on the UI and UX. So again, everyone here was kind of given their own Greek god name, but we can go ahead and edit our own names. If you open up the Page Presence toolbar and you click Edit on your avatar, you'll be able to change your name. Go ahead with MC, and I'm feeling a little bit red today. Now I should show up as MC with the red avatar for everyone here.

Let's go back. Awesome.

And I like that everyone has already added their name, has started testing out different features and seeing how it feels. Hopefully this is smooth and real-time. That's what we've been going for.

All right, cool.

So that's for the most part what we have been working on. And again, it's taken a very long time because of how we built it and what's come out. On the other side. We hope you kind of enjoy playing with this, and at the end we'll actually help anyone who wants to set up their own server go ahead and do that. We'll do kind of a little bit of a tutorial and just walk through step by step. And yeah, for now, just kind of— if you want to go ahead and break Athens, at least on my side, it seems like the client is a little bit frozen. Now I'm curious if that's popped up on anyone else's side. Or if that's just me. Okay, may just be me.

Cool.

So I'm gonna go ahead and open it up for kind of the AMA and FAQ. Jeff, if you want to go ahead and take over.

Yeah, I mean, well, I mean, first, this was like really, really awesome. So I knew I had a lot of anxiety seeing all these people in The Graph. I see our engineers laugh when they— I think they had it too. It's interesting, it seems like one or two people have trouble connecting Cortex and Isaac, so we'll look into that. But yeah, I mean, we would love to answer any questions you have about how we designed the system. Yeah, just any questions about what's next as well, if people are curious.

Oh, and actually, while we still have everyone here, since we do have like 41 people here, and I know it is Thanksgiving Day, people kind of jump in and out. If you did want a pop-up for this event, as Jeff mentioned at the very beginning, a pop-up is just kind of like a badge to commemorate your participation and attendance in this event. It's kind of a special holiday, and we just kind of want to give a little token back back to you guys and figure what better way than to do it as a non-fungible token. So that's, that's what a POAP is. You don't need any kind of Ethereum address to claim it. You can have one, but you can also just use your email. And definitely suggest holding on tight to this one because we've got quite a few good things coming your way if you have one of these badges. So yeah, thank you for joining us today and DM me if you'd like one. And then we'll go from there. I'll let you know how to get one. Yeah, cool.

Awesome.

So yeah, I'd love to open it up to anyone, anybody's questions now. And then after this, if people are interested, we can also spend some time to help others self-host their own servers if there's interest there. We figured that there's not as many people that want to do that than just have general questions. So yeah, we'll I'd love to open it up to any questions.

Hi, Tev. Martin here from Germany. I've been following Athens for quite a while. And in the beginning, I think you had plans of persisting and reading from Org mode as well. Is that still on the radar or are you like, is it now so it's database agnostic but you definitely need a graph database?

So I guess there's 2 questions there. I need you to re-ask the second one, but for the first one, I don't think I ever said that we wanted to persist from Org Mode or support that. In fact, that was something that I did not want to do because that— Ah, OK. Maybe I— Yeah, that's a specific kind of feature set. But Logseq, which is one of our close friends and frenemies, you could say, or competitors, they do support Org Mode. And that is much more the thing that they're trying to support.

Yeah, actually, I'm using Logseq right now. And I like the idea of persisting to files in a standard format. And I was thinking, well, if you're backend agnostic anyway, would this be an option, or do you need specific features of a graph database like Neo4j or whatever in order to get the functionality?

Yeah, you don't need any specific database. The model that we have is slightly different. Instead of saying, okay, like you need to model this in a certain way, we instead say, here's the list of changes that actually happened in like a certain format, which is stuff like, oh, I created a page, I inserted a block on this page, I inserted a block under this block, I moved this block elsewhere, I wrote on this block. And personally, us right now, we use a Datalog database to model these relationships. But the important part is that, like, the client says, I did this. A server sees this. The other clients see the same thing. And they all are able to build a state with what matters to them. Now, like, if you aim for full fidelity, then you should in some way encode all of this information, right? But you can also aim for partial fidelity. Maybe you only care about, like, maybe you have clients that only care about stuff, something that happened on a particular page, right? So you look at all these operations like, I don't care about this, I don't care about this, I'm only storing this stuff. So I think you should be able to model that on pretty much everything, but I do think it would be hard to model these graph relationships because a lot of like the positioning is about parent-child relationships. I think that would be harder on just like a plain text format, or at least you'd have to find like some kind of encoding that would say You know, this is unambiguously a location or a block or whatever, and whatever is like, you know, separated by some kind of formatting is unambiguously somewhere else. But if you could, why not?

And basically, the— what you mentioned, these changes being sent back and forth, so you've built a CRDT for these block structures, or is it something Custom?

We just kind of formalized the operations and made sure that they contain all the information so that the operations themselves are deterministic. We did not do a CRDT because— and this is actually a point that I don't know if it's my ignorance or misinterpretation or if it's actually true. As far as I can tell, if you want to use a CRDT for a very long term, every client needs to store the whole log of operations forever. And that seemed very onerous for the timescales that we're looking at. Like, if I want to say I want to keep my data for 10 years and I want to connect with a new client, that client getting the granular log of operations for all 10 years, that seems harsh. I'm not sure that's even feasible memory-wise with the machines we have today. At least for like a graph with a certain amount of activity.

I would assume you can do snapshots, but I haven't read up on that.

I think CRDTs allow you to do some recompacting, but like then the clients that have changes from before that point in time, they wouldn't be able to participate. This is my understanding. I might be very wrong here, but this is the information that I could get on the topic. We do not have this hard requirement that, like, it cannot be a CRDT. And I think there is probably a way where these 2 things meet and might be just compatible. Like, this is a bit stricter than a CRDT, so a CRDT should be able to just do it, right? But I've, like, we've looked, we haven't really looked at trying to make it in CRDT, like a concrete implementation with a CRDT.

Cool. So thank you for the question, Martin. Also looking at some of the Athens— at the very bottom of today's daily note, I created a questions block and just transcluding people's questions there and feedback. So feel free to do that, write it underneath your own and transclude it, or just write it directly there. Brandon asks, how do I tell the author to block? We do not have authorship yet, and you can see this in the release notes for today's release. There are some basic things that we don't have yet, like undo and redo, image and file support, persistent users across sessions, the locking of blocks. So it's possible to override someone. If so, you should just avoid that by looking at the avatars and seeing that someone else isn't there. We don't have things like comments yet or mentions, notifications, or publishing shared pages. So like pretty table stakes things for a collaborative editing experience like Google Docs and Notion, things that you would expect. But those are the other things that we're looking at now. And yeah, this is just the beta, but there's a ton of ground to cover here. We think things like comments could be very compelling. No one has done comments yet in knowledge graph, where you could have very interesting discussion. You know, people— that happens in Google Docs, right? You have like the most interesting discussion happening in the margins. You can't actually reuse that in a separate context. It's second class. But if comments are just an extension of a block, that is what we could do. But figuring out the usability there, those are some new design constraints, right? Because it's a little different from a block in some ways as well, in that you don't want to probably reorder the comments. You don't want to edit someone else's comments. So these are things that are being remounted. And yeah, let's see. Cortex mentions Hyperness has comments, not all done yet. So again, you can't reference those comments. So it's not really a block. But why not? Like, why isn't it a block?

Can you—

Can you guys hear me? Okay. And there's just basic usability things, like I think we've all experienced now that we're on a big page where the open and close— Mihai, are you trying to say something? Oh, we can't hear you. I can't hear you yet, but I'll continue saying— Yeah, there's just small usability things, like questions around, like, if you open and close a block, does everyone see that? Because in an outliner, that can be quite jarring if you're looking at something and a bunch of text expands and you don't know where you were. There's just small usability improvements there. Okay, so Rob wants us to elaborate. Can we elaborate on a shared database that is a shared graph that is database agnostic and frontend agnostic? I guess we talked about a little bit already. Basically, we have defined a small set of operations, probably like there's like 4 or 5 block operations. And these block operations are just like what you would expect, like you create a block, you edit the string of that block, and you move it around. You move the block around to a different page or to a different parent block, and you delete the block, right? There's a small set of operations that you can do with the block. In Athens. And if you look at Notion, Roam, any block-based outliner, it's a very small set of things you can do with that block. And all we describe is this very simple protocol. And a backend could just implement these operations. So in SQL, you might have just a SQL database that implements these operations and then describes how some table is being updated with those blocks. That's about it. On the front end, you could describe a different UI that takes in those changes. We can imagine a visual graph editor that handles that interface differently. So it's not necessarily an outliner, but you can imagine just blocks being created in a visual graph. We can imagine blocks being created in a messaging client. Same way a comment is just a block being created, and if it's attached to a certain block, that's all that's happening. But for a messaging client, for instance Discord, Slack, what is happening? Each of these messages is just a block. We're creating a new block. We're appending it to a list, or maybe we're replying to a certain thread. Maybe we edit it in place. Maybe moving it around doesn't happen as much in chat, but those other blocks do happen where you're creating it, you're editing it in place. You're deleting it. Same thing for Twitter, right? A tweet is just a block, right? Like with certain constraints, which is that it has to be less than 280 characters. And you can have it attached like images and videos, but like to a limited size, right? Like we could build a Twitter client and then reuse the same data that we're using in our normal Athens graph. Because those are just blocks. And so now we're thinking about different ways to extend this. And there's like, but I think like the Twitter and Slack client, like kind of interfaces that happens, they're using the same block protocol are like the most interesting ones that we can imagine right now.

I see you've been answering a couple of questions in Zoom, and I think there are a few in party chat as well. Are there any that you wanted to highlight? You're on mute, by the way.

Yeah. Um, okay, let me see. Um, there is, there is, uh, yeah, a couple of them. Um, uh, Chris, by the way, hi Chris, in like, you know, video format. Uh, I know Chris for a while now. Uh, he was asking about like what, what database, uh, we're using proper. We're actually using a combination of 2 databases. a database called Flurry, which is a graph database, very similar to like the traditional Clojure graph databases that people in Clojure and where the Clojure shop are used to. And also Datascript, which is a very classical database in the Clojure ecosystem. We use them for different things. And we are like, We want to explore using more different databases to see what different capabilities we can get because of what I mentioned earlier, that it is important that like this, we're not really bound to a particular set of capabilities on the database itself. And another question that I'm glad that you kind of like, you know, brought it up that maybe I could just expand a bit on it. It was about like doing analytics on the graph. Unlike your graph data. And, you know, obviously you kind of want to get as much information out of what you have, what you have, what you put in. And we're trying to be very open about this sort of thing in the sense that we're trying to make something that not only your data can exist in Athens, but you can also use your data to, like, use other tools that you might have to process this data. Because at the end of the day, kind of like the bring everything into a single place, and that's the only place that you can use, like that you can play around with all of this information. It kind of really leaves behind all of these existing other tools that are extremely good at processing data. I think a very good example for people that are just used to wrangling a lot of data is whatever is here on the graph, you can probably imagine being in a CSV or some other format. And like, you know, what you'd consider to be like a more like basic format that allows for a lot of interop. And then that kind of opens the door to putting it elsewhere. Like you can just like dump it on some heavy-duty processing engines. You can dump it onto some other graph database that lets you do more interesting things with the data that You can't do here. Uh, you might like, uh, change parts of it. You might, for instance, dump it, do some mass transformations, load it again. Uh, all of these are interesting cases that I think we're very well positioned. Oh, hey, Nune, how are you? Oh, wait, what?

Hey, thanks for calling.

Oh, there's someone talking.

I think someone is receiving a phone call. Can you mute yourself?

She's holding up.

We don't know who it is.

Should be good to go now.

Okay. So there's like this whole world of tools for processing information, and I think we're in a very good place that we're like, we're open source. What we're trying to do is open. We're trying to provide a language for people to interpret what we have, that you can actually use this information elsewhere, and you're not just limited Like, we're not the gatekeepers for what you can do with the data. And I think that's an interesting property when you start to evaluate tools that are meant to work in, like, you know, long time periods, right? It's like we all get hit by, like, you know, buses in different countries at the same time. It's like, oh no. Well, your stuff still works. You can still get this data out. You can still do interesting things. That's a nice property to have. That was it for me. Matej, please pick up. The silence is getting uncomfortable.

So there are more questions in the graph. So Rob asked a follow-up question. Just to clarify, so this basically means that you just need to specify what a data transfer information looks like in any given backend and terms of those block operations, then the Athens frontend could render it? Yeah, that's exactly what it means. So we've implemented it on the backend, I guess, with Flurry. Yeah. But you could implement it with SQL, any SQL variant. You could implement it on MongoDB. You could implement it on blockchains. And basically what we've come up with is a protocol, like a language, or like the fundamental operations. The fundamental operations that any backend can implement. And there's only like 7. No, there's like 10. How many atomic block operations are there?

I think Alex knows that off the top of his head.

I don't.

Okay, there's 5 blocks, block operations, there's 4 page operations, and then there's like 3 sidebar operations. So that's like 12 operations, I think. And again, like the sidebar—

That's about right.

Yeah, the sidebar ones are just the sidebar. So like maybe like those aren't even like that important at the end of the day. All right, like really we're just talking about blocks and pages, and those are the 2 primary abstractions we have. So far. And off of those 12 atomic operations, like, we ourselves have implemented a bunch of composite operations. And basically every— everything that happens, it can be reduced down to those factors, like the lowest common denominator, whatever factors.

What do you guys expect would be the hardest operation on the block, like from the atomic, like create, save, open, move, or delete, was the one that caused us most problems implementing and actually was the hardest eventually? What do you think?

Sonny said move. That's my guess too.

That would be my initial guess too.

I guess—

I couldn't implement all of them. Which one? Which one?

I'm gonna guess rename.

Delete?

No, rename is move. Like rename, we do rename pages. Blocks, we don't address them by content, so we can only move them. Anyone else? Guesses?

Usually deleting is hard because you need to tombstone it or something like that.

Yeah, delete is the biggest one, like by far. is the most complex one that we have. Next one, next one is move. Indeed, next one is move, like remaining indexes on the source and target. But the delete turned out to be like the most complex operation that we have in atomic operations. Everything else is like nearly walking a park compared to that one.

Yeah, because when you delete, you can have transitive dependencies and It creates a mess.

A lot of that stuff. Like, if you, you do have to consider all the tree, like, subtree that you're deleting, search if there were references to those things that you're deleting. Like, it really explodes very fast. But, um, because it's atomic, we actually have it tested very, very well. And not like within the— like, we had the— I think about like at least 6 different places where we kind of did it before, uh, in custom ways. And now we have like one canonical way that the We could actually guarantee a lot about.

Yeah.

Do you want to talk a little bit about move, Alex, uh, and like our semantics around move? I think that opens up a lot of, uh, really possibilities in concurrent editing scenarios.

I don't know, would you like to talk about it? I don't know, like, I think a lot of inspiration very came from you, like, uh, with addressing, right?

Like, uh, Okay, I'll talk a little bit, but it's the sort of thing that whatever intuition I had, like, it changed a lot as we worked all together. Like, there is this hard problem where, like, you're on a block and you're trying to, like— like, you don't think, like, when you're pressing enter on a block that you're going to insert something on, like, Block number 10 or 11 or whatever number, it doesn't matter. You think that you're going to insert something on the next block. And like our protocol, like our operations to change things on the graph reflect this. Like there's no concept of block number 10. There's only the notion of before, after, and first and last. Because we found this was the only thing that had like even a chance in hell of working when you, you have concurrent operations. They all have to be relative. You can't have like all of this notion of absolutes. Um, and that's, that's where we expend like a significant amount of energy to make sure that these things make sense, um, in a concurrent world. Um, because—

Do you remember how long, how much time it took, uh, debugging those, uh, errors that we had? Like, uh, around that stuff. Like, I, I blacked it out. Like, um, I don't want to remember it, but, uh, I think it was at least like a week or, or not even, maybe even 2 weeks of, uh, actually it was something like, because like before we were on like PKM, which basically like you're the only editor, right? So you can reorder things with, um, absolute numbers. You can say like, yeah, this is going to be like block position 11 because you executed enter on block position 10, that's fine. But now, now we have like 16, 17 people on the graph. Like, that's not gonna work, right? Like, it's just guaranteed not to work. But it took so much time to figure out like, oh, this is really addressing issue that if we try to address things on the wire, on the protocol, by by absolute orders, we have strong guarantees to fail. Like, really guarantees to fail. Like, there is no going around it. Like, we're lucky if it's gonna work, but we can actually expect that it's gonna fail. And, uh, well, that was, uh, like, it wasn't easy to figure that one out, how to do it. But at the end, like, how we talk about it, right? Like, look, you say, like, You're hitting enter and you're inserting block just afterwards, right? Or you're inserting first child to this block. Like, that's exactly— this language already had the solution, right? Like, we just had this wrong notion on the wire before, but the solution was already in the language. Now we talk about it.

All right, so I'll knock out some of the yes or no questions. I see Chris has his hand raised, so People asked in the questions page of Athens, is it possible? Is my connection secure? Maybe TLS. I don't know if we don't. I don't think we have TLS yet, right?

No, we we don't. But the way we structured it, so the server deployment is three Docker images. One is for Flarey, where we store like that's our ledger for event store. Then we have Athens server that relies on. Flarey, but it doesn't serve things directly to you. On top of it, there is NGINX server, and NGINX is like reverse proxy for Athens. So if someone wants to actually have secured it, it's the same as securing any kind of NGINX or Apache. You have to get your certs in place and configure them for NGINX, and you're good, right? Like, you, you'll have the HTTPS connectivity on it. Um, no, actually, no, no, you're not good. I think our client is not prepared because we're doing WebSocket and not secure WebSocket. We're not recognizing secure WebSocket and we're not giving you an option, uh, to switch to secure WebSocket. Yeah, I think, but we never tested it like that.

We never—

But it isn't very hard. It's not like we have to integrate certificates. We would actually Delegated to NGINX that we have in front. This one would have to— like, you, someone, administrator would have to configure NGINX to actually use the certificate. And on the client side, it's, uh, it should be fine. Like, it should be easy. It would require some, some minor changes on our side as well, but it's totally doable. But not now. We don't have it now.

Um, JS asked Is the server code open source on GitHub? Yeah, it's in the same repo that we've always been using. And what is the license? It's Eclipse Public License 1, which is pretty good, pretty permissible. Chris has his hand raised in Zoom. Chris, do you want to unmute yourself?

Yeah, my question has to do with portability. I presume that this is designed—

Oh, Chris, sorry.

Unmuting. Yeah, just unmuted.

Portability.

Will this eventually be able to apply to any device anywhere?

I mean, yeah, so we could write clients, we could write mobile native mobile apps using this protocol. We could create APIs for it. We could create command line interfaces if you're hosting the data yourself and you have access to the server. So yeah, it's supposed to be universal.

And the data— will the data—

could the data eventually be hosted off my site or my server site to a site that would be accessible by many people, many devices from many locations?

Yeah, we can implement that. Yeah, shouldn't be too crazy, I don't think, especially if it's static. That's, that's like a known problem with Roam, which is that because they're using Firebase, they have to load the entire graph at once. Firebase isn't like a real server, it's a platform as a service. So that means if you wanted to share one page, you would share the entire graph. And when you load one page in Roam, you have to load the entire graph. For us, I could see us easily making like a static, like, single-page URL, which is public. And a lot of people already want to do that with a static Roam or static digital garden. It should be as easy just as taking a snapshot of the content on that page and publishing it publicly. That would be fast. And then one final thought. Notion has a lot of objects you can put into the page as part of the system.

Is it your intention to continuously add objects, or can the pages receive objects over time as you develop them?

Yeah, I think that that's a natural implication of the system that we've designed, is that it supports the growth and development of more features, more kinds of components, more kinds of data. So yeah, I mean, that's certainly possible with the system that we have. It's like Notion but even more flexible, I would say.

It's like a part that was a bit surprising, but I wouldn't say that I'm super secure of this right now, but When, like, you might have noticed that when, when Jeff and Alex, like, kind of went through what operations, like, this protocol defines, there wasn't anything there actually about references. And you're asking something similar, which is, like, how, like, over time, how do you show more stuff? And you can— one way to look at that, obviously not the single way, but one way of looking at that is, like, Oh, like if I write something, can I, can I make it be interpreted in a different way? Like, you know, double brackets means this, you know, hashtag means this,@ maybe means this, etc. So far it actually looks like maybe you could have different parsers, at least with what we have right now. Definitely it looks like you could actually parse the content and show different things on different clients. I wouldn't be— I wouldn't put my hand on the fire that this property will hold indefinitely. But this is an interesting property to have that maybe, maybe we can end up with content being open in the sense that different clients can interpret content in different ways. And you can have, for instance, block contents that will actually be rendered and used as different elements like in Notion. We don't really have like any first party of those right now. But it is like an extensibility avenue to explore. And like, we're kind of defaulting a bit to being open instead of closed in that regards, because it's kind of like, it's kind of like a tall ask to expect. Well, I don't expect myself to come up with all the right answers for everything. So, you know, it's kind of better to be open than closed in regards to design.

I've been thinking about that problem for the, for the last days, and I think a really nice approach would be something like CSS-like where— Like I was doing web scraping at the time and there was a tool called Selector Gadget where you just click on a few elements in the page you want to scrape and then it finds a CSS selector which will which will generalize over the elements you've selected or deselected. And basically that in combination with custom template rendering would allow you to, well, write a block, click on some of the elements that you, for example, want to have show up in a Kanban board, and then give it a different HTML representation for those blocks. I guess that would be Rather intuitive.

Like, I can imagine it's like a custom client doing that. I don't know how, like, we could just jam in CSS customizability right now and still be like 100% safe. Because that, that is a quality right now, I think, in Athens. But I, I don't have good answers for like real good customizability and like extensibility around stuff like, like in-Graph CSS and JS or other things that would fundamentally change the client.

It's the fundamental problem of sandboxing, right? Like how much we can allow you to run within the process that will kind of provide guarantees around, right? Like, it's a really hard problem. And there might be better ways to extend, like, provide much more value than extending, like, through those kind of, like, JS and CSS means, like Slack extensions applications, right? Like, they Provide tremendous amount of value, but they're not really customizing what you see in Slack, right? Like it still preserves the basics of the Slack, except like you just connected those machines to it, right? Like with via commands, or in our case, maybe like right sidebar, or like we have a command menu as well. So this might be like we we don't know actually yet. But it seems like CSS and JS are very, very risky avenues to take.

I wasn't even thinking about CSS itself, like the CSS for HTML version, but an approach like that where you can— where you have a lightweight syntax of selecting parts of your block tree and then saying, okay, this part of the block tree that I've selected, I want to display in a different A different styling with some HTML template or whatever. That doesn't even have to be— doesn't even have to execute custom JavaScript code in some cases. So for example, if you want to create a table out of something, you would just select some— all the children of a block that has a property table and then make that into Into an HTML table.

So what we did with this RTC effort, we basically changed the engines on the plane while we were flying. The whole how we treat the database, what we do with a database is fundamentally different. Everything is expressed via atomic operations now. Those can be transmitted over the wire. And we have a protocol that guarantees ordering and We can, like, we're really confident that this part is stable. The next avenue is really the frontend as well, like, to look how we can make this one better, right? Like, because we, like, this one really remained the same. Like, we didn't change much and we still have to look at that, like, because we opened a lot of possibilities with how we treat the database. Um, how can we improve the frontend is, I think, one of the next things that, um, we really want to look at. And maybe then we can have some kind of extensibility. I don't know yet. Like, uh, it's a very— it's a tough problem because, like, you, you probably would like to have those things as, uh, like, that you could influence with customization, right? Not like just, oh, those are predefined themes or whatever. It would be nice probably for users to participate in this creation, but I think we haven't had the time yet to really think of it. Like, so far we've been really making sure that the graph itself is stable and not losing data, not crashing on Yeah, makes perfect sense. Cool.

Also, in an interop world, you can also imagine that a lot of these cases, like at the very least, could be something like you send off, you select like a list of graphs, and then you have like some, something else listening to the feed of operations on your graph. And like when you see, for instance, /create table, what you actually do on this thing that's listening is it pulls all out of these relevant blocks, Creates a table, uploads it somewhere, and then adds a block with an iframe to the place that you made it. Now, like, I completely understand that this is a bit roundabout and junky in some ways, but in other ways it's also really powerful because then you kind of— you have a way of breaking out. Like, you don't have to do all of this inside of Athens. You can actually use Athens to communicate elsewhere and to trigger behaviors and then have those behaviors be fed back to Athens. Um, oh, sorry. Like, I'm not kind of saying that this can happen right now. I'm saying that what we have does, like, open the door to do that. Like, for instance, we don't have an API, right? But we can do an API that exposes this sort of thing. Uh, and then it ends up being like, you run your server, you can, like, hook it up to Zapier or whatever. And now all of a sudden your server actually does whatever you want elsewhere. Right, and you don't have to just rely on Athens doing exactly what you want.

Cool.

Lots more questions and comments in Athens and Zoom chat and Discord chat. Yeah, I don't know if we should try to answer all of them. This seems to be just— if you really want to— okay, let's see. This is a good question, actually. Chris asks, what about performance when compared to Roam since the data model is different? Philippe, you want to handle that one?

I'd expect right now that Athens would probably be slower than Rome. But I also expect that— so like slower in the general case, that if you're doing the exact same things that you're doing in Rome but in Athens, I would expect it to be slower. At the very least, Rome has a lot more mileage on its UI. On the other hand, Rome so far does not have— sorry, I don't know this since I left Rome. Maybe they If they have some kind of dedicated server, I don't know about it. And that actually opens the door to doing some kind of optimizations that just don't seem possible right now on Roam, chief among which I'd say is single page load. For anyone that has a large graph on Roam, you are— you don't have this. And I don't even mean that you don't have this for sharing. I mean, like, it's just not a possibility for you to have this even to edit your own graph. And the question with single page load and performance is not— it's not kind of like, oh, it's sort of better, but it's kind of a matter of, of what the total effect of a change. If in the ROME model, the total effect of a change at some point is going to be you needing to stream— not stream, like download the whole graph. then the bigger your graph grows, uh, the slower it will get over time, and you just don't have any options around that. Um, so like you do a small action, which is like insert a block, and you get a big effect, which is next time that you load, you have to download the whole graph. Um, but since we are able to section stuff off in pages, or even probably less than pages, we can probably even like, you know, just give you the contents of single block and have a client run off the contents of a single block and its children, then suddenly your changes are scoped. You're doing something, and instead of affecting the whole graph and having to download the whole graph next time, you don't. So I feel that the performance model is able to be better. And that's simply having a server enables you to do even more on that front. Like, I'd expect that before this actually starts being a real topic, we have to have really robust import/export and variations thereof so that we could actually do that comparison and be honest about it. It's like you have a huge graph on Rome, you load it into Athens, what do you see? We haven't like a fully fleshed out generic import/export that we can adequately do these comparisons. But once we do, that's the point at which we can say, okay, this is how we optimize it and this is how it got better.

Yeah, Philippe, someone answered this question, but someone asked, is it possible to have an offline copy in case my server is down? And I didn't access the docs to fix it. I need to access it to fix it. Yeah, we're working on this kind of snapshot save/load feature right now, and that's probably gonna be the first one that makes us feel extremely comfortable of any crashes happening, to always be able to recover from it. That one's The first thing that we're prioritizing right now after this beta launch.

And we'll—

what we will continue to be optimizing and focusing on from an engineering perspective first, which is no data loss. And very like— that basically just means good recovery modes.

Jeff, there was a question about commenting and chat, I think between Brandon and Chris perhaps. Let's see if I can actually find it. Things have been kind of closing and opening. I don't know if anyone actually wanted to bring those up. Brandon or Chris, but you had mentioned a few questions around what comments would look like and mentions and so forth.

Yeah, well, first, I guess, is there any appetite for people to try to self-host other Athens? Because that might take 20 minutes, and I guess not everyone wants to do that, only people that self-hosted things before. Really into coding, but if you're interested, just drop it in the Zoom chat or Discord chat. Just say you're interested. Otherwise, we can continue asking questions like this. So, and we have docs for that as well. It's in the release notes, but it might just be easier if we're doing it live. The question today was. What might chat look like?

I think it was just kind of a more general question around chat and comments and how they could kind of integrate with the graph below. I'm still trying to actually find the actual message here. Yeah, maybe if you just want to chat a little bit about the idea of comments within the graph.

Yeah, just very generally.

Well, I can expand on that too a little, Jeff, if you want, because I think it might be from the parent graph, in the graph that I was talking about.

Yep.

So comments and chat are interesting ones in a graph because on one hand, you're in an outline and you're outlining content and you're creating a graph of information. But on the other hand, in a shared graph, you're trying to interact with others and you're trying to provide feedback on things. You're trying to have more linear and real-time chats or just more asynchronous chats. So there's all these different communication styles happening in one place. And what can happen is that they can kind of compete with each other. Like if someone just tries to comment on something by nesting underneath it, then it disrupts the outline structure and the authorship of the original thing that was going on. So you do want commenting to be kind of offset from the thing that you're commenting on as either a different layer or referencing to a different part of the graph, maybe that's designated for that sort of thing. So yeah, yeah, there's a bunch of interesting open questions and problems in the kind of commenting and chatting. that space that, you know, I'd be interested in hammering around. I was kind of musing on the idea in the graph itself there for a bit.

We've been kind of experiencing this like the last few days in engineering team. Like we're working out ideas on a graph, on a shared graph itself. And, you know, Sid makes a proposal, I make comments on it. Philip does comments on it, and how do we do it without actually? It seems to me like commenting like that is kind of like voting, right? So we don't want to be influenced by other votes, right? Like initially you just want to like kind of like brainstorming, right? Like just your ideas from the source. So basically for that, what we use, we like we reference the blog that we're commenting like on each of like I have on my page. a task for to, to, to comment on Sid's idea, and then I block ref Sid's ideas and comment underneath. But that's not the way to go. Like, it is something, but apparently that's not the way to go. Like, we feel like this is not it, but we don't know yet exactly how would we do it, right? Like, uh, and that's—

That's basically what Rome's like comment shortcut does. Basically, it just creates a block reference to the thing and creates links for the date when it happened, the time, and maybe the user. But I can quickly show some of— I mean, they're not very there, and Stuart, our designer, is here to jam on it, I'm sure. But we've prototyped a bunch of interactions that people have been asking about, like mentions and notifications and comments. And yeah, very briefly, there's just the question. So yeah, it's going to be on the right-hand side. Maybe you're going to have reactions. How do we expand comments? Because there's just using the outliner as a commenting tool doesn't make sense at all. It disrupts the flow. So I don't know. I think that is We've kind of talked about this being a high-level or a high-value feature, but definitely it's going to require a lot of prototyping and designing.

I've also been giving this a lot of thought. We've been going— we kind of recognize this as a bit of a fundamental one. And at least if commenting might not be fundamental, The fact that you need to comment in, like, it's so hard to do it in graphs right now makes it like it— there is at least a class of fundamental problems. We are sort of exploring, like, if we actually need new primitives for this, like if we need stuff like block types or ref types or like more semantic meanings and the content that we input. And if so, how do we actually add these? And if so, how do we actually add these? these semantic meanings. Um, I like— I don't feel like there's, there's super good obvious answers, uh, but we're exploring them and we're, we're trying to get at the goal. And like, the, the way that it— that ends up happening, uh, like the exploration part here, I think, is the hard part.

And yeah, we know you've been thinking about these things a lot. A lot of people have been, especially Brandon, and just like mentions and notifications and things like that. And people implement that in manual ways in Roam, like Roam Collective. We've taken a look at that and like, again, like we can just look at the graph today and see what people are doing manually as like very high value things like dash Philippe. If like Philippe is responding to a comment.

Yeah, I think that taking what people are doing manually and automating it so that there's less friction is a fairly easy low-hanging fruit for like a short-term solution. But I really like Philippe's comments about looking at new primitives and saying like, maybe we actually have to add something new to the language here to make this more fluid. So I think there's short-term solutions and there's longer-term solutions. But the exciting part is that you guys are having the conversation the right way by By my feeling on this.

Amazing. Yeah.

I can tell you the one that I'm really excited about right now for like, because I thought about it for a while, for like a while, I mean like a couple of hours and it got me real pumped, really pumped, which is some kind of ref types. So like you don't need to actually change the thing that you're working on. So like the content, a block has a certain content. You don't need to change it, but you can talk about it in different ways. So like you could say, oh, I'm commenting on that block, or I'm replying to the other block, and like the interaction is defined by the ref. So maybe that's an interesting way of putting it. Maybe like I thought about this and it sounds cool, and someone else has looked around this a lot and it's actually crap. But I can tell you that I think a lot of people on the team spend a lot of, you know, their work time and their free time just like, oh, maybe this will work. Let's, you know, let's talk amongst ourselves and see where we get at.

Well, I looked at both ref types. They are cool.

Yeah, that's all I need.

Oh, what you're talking about there, Filipe, is really interesting because that's been around, especially in stuff like RDF schema, and just being able to actually annotate the edges and describe the relationship rather than just saying this has a relationship to something else. You describe exactly what kind of relationship And it kind of implies what the thing you're pointing to is. So if something— if you're commenting on something, the thing from which you're commenting is a comment. So it kind of implies the type of content without actually having to specify it. It's an interesting way to do it.

And I think that adding the metadata, there's 2 ways to do that. I mean, there's 2 general types of metadata, the way I'm seeing it, is that there's one where we're actually doing the conceptual modeling of adding, like, this is a Jeep type or a Jeep car and having specific properties. But then there's the component-level attributes where it's like, okay, this is a block in my graph, this is a tweet, this is a comment, this is a reply, this is a message in a chat app. It's like a different kind of— it's not conceptual. We're not like modeling a conceptual domain so much as we are just modeling a software interface like that for communication. And those are both like possible on top of the block, which is why we're so excited about this protocol we developed. Whether we're doing some first-class ontology of describing data and relationships in the real world or just describing different kinds of applications. Both possible.

Guys, we have still a lot of people on the graph.

I think Alex is doing great stuff.

Yeah, I do. I do want to break stuff because I know it's controlled environment, uh, and actually we've never seen so many people on the graph. Um, we know a few ways, uh, but in past we're very, very effective at breaking a shared graph. Uh, if you, if you feel like, uh, it, uh, like trying to help us break it, uh, we can tell them what they are and, uh, you can go to town with this graph and see if it survives. Like, so far we've been positively surprised, but with that amount of people, I could actually bet that something is gonna break.

I would ask people to not, like, destroy existing content. Like, you know, don't, don't, you know, break stuff that other people wrote. But if, like, you're trying to do stuff that does break things, I don't know, make like a new page for yourself, you know, go nuts. But like, the fact is that if it— if you can't break it, then we'd still like all of this content to be accessible for us and other people and whatever. Like, you know, lots of, lots of cool stuff happened here. And if it does break it, we want to try and recover it.

So I'm creating a few pages and adding them to shortcuts on the left. So, so let's try to play there. So a few things that if we do, uh, they used to be problematic for us in past. First, splitting big blocks was tough. That was one of the first original errors that we had, right? Like We compose a big block via like verbatim paste, which is like on Mac, it is like super tough combo, like Command+Shift+Alt+V. So you don't actually trigger like normal paste. So we insert it as different blocks, but actually within the block. So we're constructing like a huge, huge, huge block. And then you're— we're splitting it. So, um, this used to cause a lot of problems, especially when we didn't have this smart addressing that we have now. The second, uh, big problem, and that's because of frequency of events you can generate, is, uh, open-close. Uh, that's the fastest way you can generate events, uh, currently. Uh, and that's like everyone like Whoever does it, those events are going to travel to server. Server is going to forward it to everyone. So that's another one. So we have splitting big blocks, opening, closing, and then I think this was Jeff's favorite for a long time: hold enter. That used to be quite effective at breaking it as well, right? Like just holding enter. But as well, right, like it generates a lot of events that every connected client has to handle. And so when we start doing it, because we have that many people generating events, our individual clients will start choking on it. Idea is that like, if you cannot really do anything anymore, just stop doing it, stop doing anything. the client should recover. If it doesn't, then we did something really wrong. But, uh, the current design really should gracefully recover, right? So, so with that amount of events received, like, because we have optimistic updates, like, we're actually keeping a queue. And this— there's like a snowball effect at a certain moment that we cannot re— like replay fast enough compared to how fast we're getting new events, and then it starts snowballing and it's very, very— it's avalanche effect very fast. So these are the ways. And, um, yeah, I see already big blocks.

Is this an appropriate time for I like big blocks? Or are we gonna skip that?

We do want to sing it together.

We try to sing Happy Birthday together, but that doesn't that doesn't work too well. But we can try this one and see.

No, I think we've like we've like we we found a reason for it, right? The network latency is just basically guaranteeing poor experience.

Yeah, like when we, when we sang Jeff has to stop, it's like, why, why do we want to hurt so many people that came here to see our cool thing? Well, I'm gonna start trying to break stuff.

Let's go! My client is getting a bit slower. What are the problems we're expecting to see? I expect that clients will actually become unusable at a certain moment.

So error messages, unresponsiveness, crashing?

Yeah, unresponsiveness is what I expect, but error messages is actually what I really wouldn't like to see, right? Like that we actually error. I hope that we can gracefully— so my hope is that we gracefully will recover, right? That we will choke all the clients, uh, but that they have capability of recovering. And to do so, I'm clicking this open/close like really fast.

Definitely getting some slowness. But always recovers.

But honestly, I'll be disappointed if we don't manage to break it with that many people. Mine is really slow now, like proper, proper slow. I think I have this snowball already. Nice. Yeah, like opening and closing. Takes about 5 seconds minimum. So I'm not touching mine now. Hopefully that it will recover, right?

Yeah, I haven't done anything on my side and just what you've done there, I, I'm unusable now.

Oh, mine recovered, I think.

But so yeah, you didn't do any edits and, uh, it, uh, Brandon, it doesn't allow you to navigate even?

No, I'm trying to open and close blocks. I get like very small movements, but not even 5 seconds. Like, I still— like, I'm waiting 30 seconds now.

Yeah, like what we ended up doing around that is like, if you're doing like a lot of stuff that would make other people's machines slower, yours ends up being quite slow and others shouldn't suffer much. Mine recovered when I stopped doing stuff and waited for probably like a minute.

Uh, yeah, mine recovers. I just had like a 20-second slowdown, but then it recovered.

Mine is still affected. I did a lot of open clubs.

I even like reloaded the client and everything's still there. This is like, wow, patience so low.

No, actually I can navigate again. That's good. Let me see if I can open and close again for everyone. Yeah, I can. So yeah, mine recovered, didn't die, no need for reload as well. And, uh, Brandon, is your working— uh, your client working now? Because you mentioned like really long times and, uh—

Still no. I can like scroll a little bit, but, uh, it still, still needs a little minute to cool down.

Yeah, I, I would mention that like all of this, like the only optimization that we did was, was that it's like that it wouldn't get much worse for everyone if one was doing stuff super fast. I think there's loads of room for optimization here and to do like smart stuff. Uh, so like that, that for me is kind of exciting. Like even, even the unoptimized one doesn't, you know, horribly on the street when we just decided to do this with a bunch of people. It's like, here, look at our stuff, break our stuff in pieces, go. But we never did this. I think we had like 12 people max once.

Yeah, last time was 12 or 13 people trying to do it. And we are very, very positively surprised that it really survived. But we got cocky. With it now, and we want more people to break it.

I think this should be a tradition of ours, really.

Usually end every community call with a let's try to break it.

Every Thursday, every Thursday is a breakout party. Everyone's invited.

Not a bad idea. Well, it looks like it's pretty much fine, not broken in a. And it's bad.

No, no, no, no, no, no, no, no. I see errors, exceptions on the server, so we did it.

Okay, there we go.

I think we did it.

Are you happy, Alex?

Oh yeah, like now we have something that we haven't seen for like 2 weeks now.

Yeah, it's, uh, oh yeah, Athens still loads though.

Well, maybe you'll need to refresh.

I refreshed.

Maybe you'll need to refresh.

I refreshed and it was very slow, but it opened.

Maybe, maybe if we restart the server, like, you know, it didn't persist stuff correctly or something like that. But if we restart the server now, we kick everyone out. Like, let's— Sid, let's do it later.

I think it was your block splits again. Congratulations. But because the The exceptions.

Okay, cool. Well, we have that documented, uh, we have, we have the logs. Should we do anything else?

Um, maybe like, like a single rundown of like what it looks like to actually start the server on your machine, not necessarily on DigitalOcean or something like that.

Okay.

Yeah.

Well, does anyone, is anyone interested in self-hosting?

So what's the deal with self-hosting? Is the idea that like anybody can just spin up one of these graphs and just mess around with it? Yeah.

That's, you can host it on the Raspberry Pi.

Where does it get hosted?

Wherever you want it to be. So like, it's a Docker image. So you could host it on AWS. We've been using DigitalOcean, and honestly, I'll just go through the steps right now because it's really not too hard.

This is so freaking exciting. When this is highly functional, it's going to be incredible. Yes.

When.

I mean, I love it now, but this is going to pop. Knowledge graphs as commodity things, I think, is really powerful because it's like you don't really want to horribly break your Roam graph. But what if you make a graph for something that you're working on? You make 10 copies, serve the 10 copies, and go to town on it. If you can just spin them down, spin them up, kill them down, make copies, make backups, I think that's great.

I think one of the severe limitations with Roam right now in terms of expandability and use cases is the limitation on the number of hosted graphs that you can have. Right now, you have 3 or something like that. But if you can have a software that's accessible that you can spin up with a couple of colleagues that's intuitive enough to be able to use, and then to be able to set up these hosted ones and just fire them up and destroy them as quickly as that for a group project or something, that is so incredibly powerful. And then if you can have that reference into your main graph or elements of it, then— Yeah, lots and lots and lots of possibilities here.

Hey, imagine adding server like Postgres, right? Like, but you're just creating new schema, right? Like multiple databases by one server, right? Like, it's totally like, not now, but it's totally in realm of things that are possible, right? Like that you have this one instance that hosts multiple graphs for you and like referencing those things between each other, like that's not an easy problem. But we haven't solved it yet. What's the payment model on all this?

How is this going to sustainably make money?

So right now we don't have a price yet. And I think we're going to look into self-hosted plans for enterprises that want to self-host and just a hosted version because self-hosting is very cool. I think a lot of People and early adopters in this space really value that ownership, but mainstream users just want convenience over ownership and maintaining their own servers. You guys are— I mean, I'm sure you have self-host right now. The second that you guys are going to have to deal with maintenance or updating the software and the server and doing backups, and even if we do automate some of that, it's going to be effort. To maintain that hardware, or the backends at least. So I'll create a new Thanksgiving project. And education purposes, yeah, that's true.

Just while Jeff is doing this, I want to reiterate, like, you could just host on your laptop. Like, we put it on DigitalOcean to have like a static IP and like not have it on our laptops. You can just go do this today. I'll put the instructions on, on both, like, here on the Zoom chat and I guess, yeah, on the Discord channel.

Yeah, so we provided Docker Compose, right? Like, that's basically it, right? Like, you do docker compose up and It's pretty much it.

Yeah, so as long as you have Docker Compose, that's really all you need. All I'm showing is the DigitalOcean aspect, like part where you just pick a server to use and you choose a server that has Docker Compose already, but everything else after that just follows the Docker Compose instructions. So it's literally like 3 clicks to create a DigitalOcean Droplet.

Takes like 30 minutes— 30 seconds per minute to Start.

And right now with DigitalOcean, we've found that it has to be at least 4 gigabytes just to host the services that we're using. And yeah, that's I guess $24 per month. So if you want to do that in DigitalOcean, it's going to be more expensive than a normal SaaS like Notion, Evernote, Evernote. So again, it might be more cost optimized for us to build something that's more scalable for a large number of individual end users. Alright, so we go to the Docker, we can click console. I'm sorry, we go to the droplet. This just SSHs us into the server, and now I'm just going to copy and paste like the instructions that you could do on your own computer.

Okay.

So we already have Docker. So first thing is that you could just run docker-compose ps, and that just tells you if you have any Docker processes up. I don't even have the folder or the file yet. This uses Alpha RTC 43, but I think I want to use the latest release. So I could just— I just got to be here. Hold on, let me find the actual link. So that's Docker Compose right here. So this gets the Docker Compose that we just released this morning. And then when you're deploying on Linux, you have to create folders manually. just because of some Linux permissions things. But if you're doing this on Mac, you don't need to worry about that. And that'll be fixed in the future. And then all you write is docker-compose up detach. So that just runs Docker.

Do you want to share your whole screen and not just your browser window?

Oh, shit. Should have done that before.

OK.

I guess, did anyone see any of this stuff happening in the console?

No.

Okay. I copied and pasted this command. And I replaced it with like the newest version, 2.0.0 beta 1. So let me just— so that gives me a Docker Compose file, and that's all I need. See docker-compose ps to see if anything is running. Nothing is running. And then I can write docker-compose up. And that downloads the Docker images. We have 3. It's the nginx, which is like a reverse proxy kind of thing. And then server, we're using like a Clojure backend on the server. And then Flurry, which is what we're using as like the database, which all it is is an append-only ledger. Again, you could do this, you could use SQL. You could use NoSQL. And this just starts up these 3 images.

There's a lot of bad rumors flying around in the Chinese Telegram chat, and we don't want that to happen, right?

Sure.

If you wanted to configure your server with a password, this is where you would do it. You just specify an environment variable with your password and run docker-compose up, or you just define a .env environment variable. And you just do this before you do docker-compose up, or you just do— or you turn your Docker Compose off and then run it again. And yeah, that's how you would add a password to your server. So you can just turn it on, turn it on. Turn it off and turn it on with the configuration to change your password or to add a password. So now— and we see that we have these 3 services up. I can go back to DigitalOcean, copy the IP address, and Open up Athens. Let me make sure. Yeah, I don't know if I even have this on my Mac. I was using my Linux earlier, so I'll download the newest Athens. Open it and paste this in the chat as well if you want to try it out. But that is the IP address, and this would be chatsdb. Press the remember address, and I'm here. So anyone could join this database right now. Feel free to join. But yeah, I just created a new a new database. That anyone can join to. It was as simple as that. So, Brandon's here now, and yeah, there we go. Not too hard.

Uh, future fun.

That's slick. Yeah, not too hard, right?

No, that's great. It's funny, I, I have no background in any of this stuff, but I just recently did a little bit of a learning rabbit hole to figure out how to do the DigitalOcean stuff to self-host. So this is perfectly stacking on this little learning project I did a couple of weeks ago.

Awesome.

This is cool.

Well, you know, set it up and let us know if you have any trouble on Discord. We're going to be online just paying attention to any, any support requests for setting up the server.

Awesome.

One, uh, one thing that I would add in here, um, for anyone that's left is, uh, if you guys are on Twitter, go ahead and tweet about this if you were actually pretty excited. Um, we definitely would love to get more people with their hands on, uh, Subhosted Graph. And Brandon, as you were saying, just kind of like getting people to spin this up, um, you know, and then see what happens. Because when you're limited to 3, that is definitely a thing. So yeah, the more we can kind of spread the news about this and, uh, Yeah, it'll be great. So if you guys are on—

Kind of a follow-up question to the self-hosting is like, if you, if you do the DigitalOcean route and you choose the 4 GB thing, how, how many graphs can that support? Is that just one graph? Do you need to do that for each, or can you then support multiple graphs?

Currently one. Yep, currently it's one.

Like, we expended no effort to try and optimize like the resource usage of a bunch of stuff. It seems super possible to make it much better than that, than what it is like resource-wise, what it is right now. But it wasn't very important so far.

Yeah. Eventually, I think that's, that's when it's really going to hit potential, because that's when it's going to be able to compete with the, you know, the free hosted graphs at Roam or, you know, something else then. Like, if I could feasibly have 15 and I could bring them up and kill them and back them up and do all these sorts of things and have a little bit of fluidity for how many I'm hosting, then that's where this gets really compelling.

I think that should be not that big of a problem for us. Initial problems really were like, how do we concurrently access shared graph in a way that doesn't break it and is really reliable. Like, now that we solved that one, so it seems, right? Like, 30 people trying to kill it and, uh, didn't manage to. Challenge still stands. Like, we're like, uh, how many do we need to actually kill it? But that kind of says that we actually have a very solid model now for, like, shared graph. Uh, like, it's not that hard to actually, you know, enable the same server to say, like, okay, Okay, there's multiple databases now, right? Like we have another ledger for, uh, for event store for another database. That's, uh, like we can now build on top of that, but, uh, but we have this like first building block solid, right? That the shared graph is, uh, there and, um, it really supports concurrent editing. That's, uh, that's what it is. Yeah.

Yeah, concurrent editing and shared state in general doesn't have to be at the same time.

Yeah.

Chris asked if you can support only by domain name or only IP address. No, we can support domain name, I believe. So you could have subdomains.

Yeah, if you would have a DNS, if you would set up DNS for it, Like in this dialog, you can put the DNS name. That's not a problem. We just didn't, so we use IP, right? But it follows the normal DNS resolution. Like we're inputting IP addresses because we don't have names. Like we didn't register those names anywhere, but if we would put there like something resolvable, it would resolve it and it would actually get there.

Yeah, maybe we'll host our own subdomains one day. .athens, right? It's already ens. Athens is all-time high, uh, so it's gonna be even better than normal ens.

Yeah, we should have like, uh, Athens names, right? Like, uh, that's what you're saying, ATH, right? Yeah, not ETH. Nice, nice. Like a top level— I don't know how you get the top level, um, FQN. That's not easy.

It's not easy. I mean, technically .ens is like owned by some random country, I think. Still, I don't know, it's pretty weird. But if there is appetite for rabbit holes into Web3, then we're also thinking of having a community call kind of discussion party there as well, because I think there is some overlap between the two worlds. And there's some people talking about it, but it is underexplored, I think. And also why we're doing things like giving out POAPs. And also experimenting with looking into Arweave, things like that, just internally. It's good to say that hypothetically we can implement this on any backend, but actually doing it on something like Arweave where it's there forever is pretty compelling.

Yeah, the token thing is really cool. This is the first instance that I've seen of that and probably the first token I've saved. But interesting for community calls like this to be able to offer some token of attendance that you can then use for community engagement methods and like, you know, some sort of rewards for early engagers or folks that are more engaged with your community in general. It's just like a really objective way to be able to manage achievement within a community. So I'm really interested in what you guys are doing there.

Yeah, anyone— the ownership of the NFT means we can do whatever we want with it in the future. So when Athens is super successful, then maybe we'll just give some airdrops to some of those early contributors that come into the calls.

Or special graphs accessible only if you have that asset in your wallet.

Or early access to claiming your ENS name in the global Athens graph. Totally.

Well, it's infinite, like the types of things you can do with that. It just empowers the creativity to start. Even just to have it as a token of, you know, I was there in the early calls when this was just forming and like just before it popped off. And like, you just have this, you know, non-fungible token that represents that presence at that time. Whereas otherwise it's, you know, sure, sure you were.

Yeah, I mean, it's funny, some people will, depending on how you publicize it, some people will still find their way into the Discord and try to DM me and be like, I was there. I'm like, I don't know, were you though? What was the last Zoom question?

Like, come on.

But yeah, otherwise it is a really great way to kind of track that, and it's just so exciting what we can do from here. And you might get a special one, Brandon, just because you're cool. So we'll make a dedicated one for you.

Well, I love what you guys are doing. Like, it's funny, this is so outside of my normal career. Like, I work as a pharmacist in Canada and not in tech whatsoever, but I've just found myself in the space and just compelled by the innovation that's going on. So it's an absolute blast hanging out in these spaces.

Yeah, there's exciting things happening. On the horizon.

Well, I gotta dip anyway. Thanks for the invite, Jeff. I'm glad I was able to make it, and this is really cool. Love, love all of this.

Awesome. Yeah, thanks so much for joining, Brandon. Thanks everyone for joining, and yeah, Happy Thanksgiving everyone. Feel free to hop out whenever you'd like.

Being vulnerable enough to share with us.

But the graph survived. I think OX Lombard is— well, someone was speaking, but I don't think that I could hear them very well.

I just muted.

I think he's speaking on a phone.

I just muted.

Oh, yeah.

But pretty cool, huh? We didn't get the graph to break completely. Like, I've seen a few exceptions on the backend, But it's still working. Like, it recovered. It isn't any of those exceptions that we already fixed that were unrecoverable. So that's really good. Like, the server is still running and serving.

So did you restart the server? No.

No.

OK. We'll try that later.

But exceptions that we had, like— Something with this, uh, the least favorite part, uh, of mine, like, uh, the pattern matching that we have instead of parser. See, I don't know how you managed to do it, but you managed to actually get that to Stack Overflow, which is impressive. Many times.

Yeah, needs more parser juice.

Yeah, like seriously, like, uh, Like, I haven't seen parser stack overflowing, but it could also be that it is actually parser, right? Because like, I don't see the whole stack trace because, hey, it overflowed, right? Like, so I get only the partial picture and it looks like it's recurring pattern of some sort. But it doesn't happen on a normal operation or with 12 people.

Okay, so this seems like it was good success.

Great success.

I'm satisfied. Turkey day.

Yeah, I think it didn't break. It's a success. People liked it.

It was so colorful. There were so many colors. I, I, I like that so much.

I got screenshots of like the— it's the first time