 The recording is on. Oh, and I only have about 30 minutes today, so. All right. But I don't have any topics, so. Well, there we go. And I'm interested where everybody is and what you're most interested in talking about, sort of, in this realm. Fluncie and I have a... My mission this month is to share notes with a few people, and you're one of my target people to share notes with, and I want to figure out exactly what that means between the Agora and any piece of the things that I'm doing, so. Nice. Thank you so much. That seems like I'm happy to make that my objective as well, because it's something I wanted for a long time. Sounds great. And a question maybe for this group is what does that even mean? What does it mean to share notes? And I think that the massive wiki approach of using markdown files on a GitHub repo is my least common denominator of sharing notes, which is like, hey, if we're both pointing to and can edit a shared note on a shared volume someplace, that's shared notes, right? And like, what's above that? What's beyond that? Pete, you were going to jump in, sorry. I love the topic. And let me bring up a kind of a separate topic, but I feel like there's a connection between them. I've started playing around with Nostra, and I still really like it. However, so there's different things to say about Nostra. And the first thing I'll say is that morning disclaimer, it's not safe yet. You have to be careful with your private keys in a way that is not to be expected from new users. Boris in particular, Boris Mann, is actually like people who would make these kind of engineering decisions and let them loosen the field I can't trust. So I feel like I would like to have more of a conversation with Boris. There's other gut feels that he has about it. It's too Bitcoin-ish, it's too yada-yada. Anyway, having said that, at the heart of it, it's a way to pass messages to people. It's not peer-to-peer, it's actually through relays. It's a little bit like Secure Scuttlebutt, but different. So I'm all excited. It's like, oh, cool, we could do maybe Massive Wiki over Nostra. And then really quickly, we run into something that the TFTMap people have been talking about, and Bill Anderson and I have been talking about, which is Massive Wiki is markdown and files, but it's also sharing and versioning. And we've been using Git for sharing and versioning. We've tried SyncThing. We've looked at P-Jewel. I've talked about doing it just email and attachments. And it turns out that versioning is tricky. So it's easy to say, oh, I'll set up, I'll start sending markdown files, or my current version of the markdown file back and forth over Nostra to somebody else. But then they've got two copies of the same file, and then if they edit one and send it back, then we've got three copies and yada-yada. So kind of in the same way we're talking about, Matthew has finally got into Git enough to not be afraid of it or not be frustrated with it. Maybe there's a better way to say it, he was never afraid of it. So now he's excited about proselytizing to other people. Here's why you would use Git, and it's actually pretty useful. And it made me think about, I guess the way we ended up realizing that most people, most people who have been using computers for 20 years or so, it's like the way you have versions of a file is you send me a Microsoft Word document, I edit it, and I send it back to you. And it's the same file, because semantically it's similar to them. It's the same contract that they're working on. To a file system person, they've actually got multiple copies of a file that's related to, but it's not the same file. So then the newer thing to do is with SharePoint or Google Docs or HedgeDoc, let's all work on the same file and have multiple versions of it, but that file is never a different file. Unlike the revision 3 copy 2 of Pete's edit of Martha's document. So that version thing is super important. So maybe to get back to your question, Jerry, there's a big conceptual leap, which is working on one file that has versions instead of versions of the same file that are actually separate files. Absolutely, totally agree. And conceptually, I always lean toward, hey, let's keep a canonical version of the file out there and let's save every change to it. And even better if there's wissy wig concurrent editing, which we get with some fancy tools. That just simplifies everybody's lives. And if the file happens to be fragmented and charted and distributed in an interesting way, that's fabulous too, because that changes the underlying thing, but not at the cost of the mental freight of, oh fuck, there's like 300 versions of this file out there now. And this is one of the things that dismayes me or that I don't quite grok about FedWiki, which is that it is what's the word promiscuous about page replication. The moment you touch a page, it makes a copy into your FedWiki. And I'm like, I don't really want a copy in my FedWiki. I want the copy to live out where it was. And if it goes away, I want to figure out how to fix that. But I don't want copies. I don't want pages profligate page replication. To me, that is crazy making. But that's just the way my brain works. That doesn't mean that practically that isn't a good solution because super distribution is sometimes fixed for broken central systems. The FedWiki thing, it reminds me, so now that I'm jumping into Nostra and having read and thought a little bit about Nostra versus SSB. SSB, I forget the way somebody said it, but SSB is really biased towards permission to listen, or ability to listen or something like that. SSB, you bias towards not listening to people and not seeing messages. And if you want to make a connection with somebody, then you can start to see their stuff. SSB is Secure Scuttlebutt. So then Nostra is a little bit opposite. They kind of biased towards, you have permission to speak, but nobody is necessarily going to listen to you. So FedWiki is kind of, it's the same kind of opposite solution for, instead of, it optimizes for everybody has a copy, even if all they wanted to do was edit a character, a single character, they've got a copy. As opposed to let's try to keep the party together in the scary movie, and everybody should be in the same place. FedWiki really likes to split up. So I guess here I wanted to, so this is very interesting. Thank you, First Peter, for looking into Nostra, because I saw it pass by, I read a bit about it, and I was unconvinced, I guess, about some of the decisions and the trails of creating this new protocol versus maybe building on some other for this purpose. But this sounds very interesting. I would take from more of a review. I guess I was wondering, as we spoke, whether we should go into a more complicated protocol, like Nostra or something like this, necessarily now, or whether going back to your proposal Jerry of Marathon repositories and the MassiWiki proposal, which is essentially this as well. I guess it's unclear to me at this point what we will gain from, for example, Nostra or other protocol on top of that. The reason I bring up Nostra is because it's really top of mind for me, and I'm actually really excited about it. I've been thinking for a year, oh, if there was only a way to do messaging where you could follow a person, Nostra is pretty much it. And it gets a lot of things right that I hadn't guessed that you'd want. So the PKI identity works really well. It is scary as heck the way that they kind of like... I'm getting a little off track. I'm not answering your question. I'm excited about Nostra. I like to talk about it more. And Flancy, if you'd like to talk offline, that would be great. Yeah, I would love that. I visited our MatterModes for a bit, and then I contact Switch and I have it on my back. I really have to be better at apologies. The thing where I was trying to answer your question and got sidetracked, and it made me think of it right away because it's like, oh, wow, now I've got this cool message passing thing and we could pass markdown files. You have to decide on a versioning strategy. So that was kind of... And there's obvious choices. Git is an obvious choice. CRDT is an obvious choice. You know, I don't know. Sync thing is probably CRDT-ish. I don't know. But so then I was thinking about it. It's like, okay, so if I want to do markdown wiki on Nostra and need versioning, it's like as soon as you... This is also happening in my head when we're trying to figure out how we explain Git to non-technical people, right? Bill found this great video, Git for Poets, which turns out to have a better name than content. It's an okay video. It's not great. Matthew's going to make... Matthew's working right now actually on a video that we think will be better. But anyway, it's like... As soon as you... I think... As soon as you start thinking about the version problem, it's tempting to go, well, we could design something that's not as complicated as Git to use. Or we could design something that's not as complicated as CRDT to implement. And I think that's a false hope. It's like, you know, Git works... Git is... I mean, the Linux kernel folks spent a lot of time on getting Git. The thing that they haven't done with Git is to make it friendly for people who aren't programmers. But the way that you... It's built for taking turns with text lines, you know? And it's built to set it up so that you push the conflict resolution into the right places of the collaboration team. You know, I have to make... I have to resolve conflicts on my stuff before I can kind of put it back into the main branch, right? And it just does it the right way. And so I think you've come up with something, but it's going to end up being Git or it's going to end up being CRDT. I think, you know, actually, I think it's a little bit better than Git. So maybe it's maybe the thing to... There's a thing called Peejool. I'll type it in. It's actually a little bit better. It's a little bit more like a CRDT than Git is or something like that. So it is actually better. But... So you have to do versioning and then pretty soon you're into, like, figuring out how to do Git. So I wanted to, like, just... I guess I personally... I could interpret the versioning problem in two different ways. And I wonder which one is the one we are tackling here in particular, or if it's both. There's the storage, like, versioning. So what Git actually solves, for example, like, once you resolve conflicts on some user interface level, so essentially how to store versioning data in a tree. And the other is the user interface problem, which is how do you surface versions either when browsing, like the version storage, or once to record, for example. So you want to link to a particular version of something. And the choosing is related, clearly, but not the same. There's another thing, too, which I... So you're totally right. I think of it as kind of, like, infrastructure under the operation of Git. Though another thing in Git is... I think of it kind of like a man trap. And I don't know if that's going to translate well. But, you know, if you want to get into a nuclear facility, you walk, or actually, nowadays, into an airport. You walk through one set of doors, and the next door is locked, and then they lock the door behind you, and then they inspect you, and then they can let you go, right? Git has that same kind of... I'm trying to think of the database. It has transactions, right? Basically, you're doing database transactions, you're saying, I want to bundle up all of these changes together, and then I want to let them go, right? Two-phase commit from the old world of databases. Two-phase commit, exactly, yeah. So on top of, you know, how do I keep track of all the versions? How do I navigate the versions that multiple commit phase process is another part, another key part of versioning that's really hard for people to understand? But once they understand it, it goes smoothly and it makes everything easier. And Git is set up so that the places where you... the places where you have to do, like intelligent concept resolution, they push it to the right part of the team. They push it to the people who have made the changes, rather than pushing on people who have to accept the changes, if that makes sense. But then they also have, you know, like a pull request or branch merge or something like that. It still has, you know, phase commit things on the way that people, you know, merge up, I guess, or merge down. Benty? Yeah, I was just thinking and reading Matthew's posts in that video, Pete. And I was thinking that, you know, Git has a lot of features that I don't think are very valuable to this use case. So, and I don't know if you've even seen the option to where you don't have a local... I'm forgetting the term now, to like stage your changes. So changes are automatically staged, so that takes one additional kind of learning concept that most people don't need. And then it'd be nice to have something set up, which I don't know if this is a built-in Git, but towards always pulling latest. So something where someone, and even something that auto commits, like so, you know, you're looking for all use of the file, it pushes it up, even if it's in a, you know, if there's a kind of a dirty branch going on it. I think using Git as a back end is still kind of useful. But I was just thinking about, you know, what are some complexities we could... that aren't serving this use case that can be shut down? Yeah, you're totally right. There's definitely... there's definitely a lot of advanced capability that has no usability for anybody who's not a super advanced Git user. And you kind of want to front end to the Git stuff. Yeah, I don't know. It'd be that hard to build an app that runs a Git instance locally and does all of that. Even the Obsidian Git plug-in is, it's got the fancy buttons, stage and push and pull on that, but it's also got the super button, which is just backup. And it does the, you know, it makes sure that you do the commit and pull in the right order before you push just magically with one button, right? Yeah, but even maybe something that doesn't have a button. Yeah. Although I have to say auto commits, timed auto commits, there's a little bit of... I mean, it's not having time, but there's also, it's also nice having semantically important commits and actually groups of, you know, stages. Yeah, and I guess maybe there still would be nice to have a save button, but right, so they, because people understand that concept often and have the save do a push. So a concept of a save is I'm saving to the central repository for the night users. And maybe I'm saving, you know, I've made important changes. Yeah. Yeah, I think, yeah, having, yeah, a way to indicate this is a big and important change, you know, kind of like, you know, the way I think about, of course, is semantic versioning, but that means nothing to the average user. But yeah, some way to say, labeled in Google Docs, there's labeled versions. So something similar to that. Yeah. So, I guess going back to the original, like the original proposal, I guess, which is, you know, like start with get a markdown and, or find some data and see how far we go. I think this, everything you're saying sounds very interesting to build on top of that, right? Because, and I actually started experimenting with this, but I didn't go very far. But you know, like, for example, like conflict resolution for wiki files. So for massive wiki files, whatever, you know, like nodes, anything that is, we'll see, unlike our liner base, you know, you could imagine, like essentially coding an auto-merge, like procedure for it, that, you know, can spot the patterns that are supported for auto-merge and merge for the user. That's eliminating, you know, this high age of like, oh, now we need to surface the user somehow a way to resolve, you know, to do a merge. So, and there, there's also like a bunch of scripts going around, I guess, which are like auto-push and so on. And you could imagine, like, and they are all like, all the ones I have my own, and it's crappy, like, almost, I think, but it works on me. But, you know, I could totally imagine, you know, like pushing to a branch and then once a day doing like a day update or something by default instead of, so, and I guess here as well, like if we just remain on, on Git plus maybe these utilities, I will say my hunch is that we will have like a really high chance of like being able to collaborate with all the people who are starting from Git, which is a lot of people, right? So, yeah, and I guess just going shortly back as well to the versioning. I guess I asked as well about the UI. From the point of view of the user, like the way I was thinking about this, and you know, of course the question is how will you like link from one Git repo to the other at the particular version without having an API that actually, you know, can is aware of two repositories and manage that. So, first, I guess you could have the API and massive week of the hour that could actually provide a service of trying to like do inter-git links. So, you know, that's one way so like centralization or so on. And the other would be like time-based versioning, which is something I don't know but like to some extent, you know, I could totally imagine having like a format for week-illings, which is like I want this week-illings and actually this one now. So, then you just can say like add time-stamp and then, you know, to some extent you see time-stamps or something like it's simple. You could imagine then, you know, that being on the burden of the receiving size to say, okay, what is the version that actually maps to its time-stamp? I have local information in the tree so that, you know, or do I say it or something. So, from the UI side of things, I'm not so sure it's the most critical problem to solve the versioning one. But maybe I'm convincing myself just because it's very hard and I don't know how to solve it, right? Well, what you just went through is a bunch of versioning strategies. They're kind of more user-friendly than you know, then get. And I think that's okay. As long as we're kind of thoughtful about it, I'm not getting echoed. Yeah, but I'm happy to explore many of these and like for now I'm just ignoring versions. It's like you link to something you go to head essentially. For linking or do a timestamp thing or something like that. The thing where you have to figure out you have to have a versioning strategy is having people collaborate on what is essentially the same file. I was just thinking one other thing I kind of noticed the difference between Git and say like Google Docs is the difference between file-based and messages. So the if people are making conflicting changes because Git doesn't have a process of saying oh I made my changes here. It does kind of know the version it was on. Although I don't know if it retains that information. But you know saying I typed in these letters between these other letters something more explicit of what the changes are would be an interesting thing. So some of my new apps everything is message-based as opposed to object-based. Which is what Git really is. I don't know how to incorporate that idea but that's one thing I'm thinking through. So it's almost like I want a layer in front of Git that's message-based and then Git on the back for versioning. So it would be like a CRDT approach for example. I looked at CRDT that will bend your brain. Pete said well you can't do something simpler than CRDT. It's like well I hope we can. Because there are some things you cannot do within that restriction. For my two hours of watching videos it is it is a CRDT is something like a few people understand it and then the rest of us have to get their libraries. It creates an absolute reconcilable and I just would like something a little bit better than Git but I don't think it needs to be to that level. I know I'm disagreeing with Pete's assertion from earlier but I kind of think if we get just kind of message-based then it kind of takes care of the 20 but like I said I don't know how to do all how to combine all that. I've been down that track a bunch of times for like 20 years and 80% doesn't work. 50% I'm talking about taking it up to 80 as far as not versioning but as far as conflict resolution. So if I can still I mean like you have human interaction it's like oh well these two people made these changes but the sections overlap what do you want to do here and it's kind of like oh delete the whole thing and rewrite it. I was hoping CRDT would be easy but I'm Pete you have your hand up from earlier are you completely sorry actually I never raised my hand. Oh that's interesting. Oh never mind I'm seeing an icon that's over your face and my display but it means that there's one hand up which is mine but it looks like it's over your this over your icon that's very weird. Yeah yeah I was taking that as your hand being up. That's an interesting UI. Oh yeah okay so Pete's in the middle of my screen probably like Jerry and when the hands are up it pops up on okay interesting. So let me jump in for a sec since I'm the only person who had his hand up mistakenly and earlier in the chat I put a whole bunch of projects that are trying to solve exactly this damn problem some of which are contemporaries and new things like the NoSphere protocol that Gordon Brander is doing, Cosmic, Paul Roney Fishin and also Rich Burton with his distributed operating system DXOS they are all solutions to this problem. Every blessed one of them some of them build on top of IPFS some of them are doing something independent and I don't have any technical chops to actually make the comparison but I think that going to some of these state-of-the-art answers and trying to make that comparison that way might save us a little bit of time and effort and blood under our fingernails because Pete you've been butting your horns against this one for a very long time and you're out there looking at, you know, Master and SSB and stuff like that so I'm trying to figure out how do we A, architect simple things right now that cut through this and skip sort of like elide the problem and slide past it which is what GitHub does for me right this moment even though I find the reconciling of differences of concurrent edits of top GitHub to be abysmal and a real hindrance, a real barrier to cooperation or collaboration so how do we elide it? B, how do we cut through this thing so that we can then shift over to one of these highly functioning platforms and become test pilots on it and go crazy using it et cetera et cetera I'd be very happy to do that and then last thought I'm hoping Rich Burden can show up in these calls to basically demo what it is he's built and what he's doing is extremely open and solve a whole bunch of these problems including distributed identity and there's sort of a whole set of layers of things that need to get fixed for the kinds of collaboration that we're working toward are going and I think he's been working to try to solve a lot of them and he has working code that's really quick and nifty. Sorry was this mentioned before I hopped on is the project public somewhere? You can so I'll put a couple links in the chat and we didn't talk about it very much I mentioned I think last time I was here that I think I mentioned on the FreeJerry's Brain call that I had talked with him and had an update and that I had invited him into either FreeJerry's Brain or Fellowship of the Link or both to sort of present what he's got which he's happy to do. Nice So I will add some links right now Oh go ahead Oh no you work Yeah So I was thinking I do think that like IPFS is probably the strongest in this space but it doesn't actually and I think IPFS great too but like there's also like sorry I got here late but I'm assuming we're talking about like syncing people's pages in some way across sites yeah so the other thing that sort of opens up as a possibility though apparently my work is blocking me from accessing it but WebTorrent is the other one right and I believe WebTorrent does work with IPFS and and like it's a very straightforward tool that allows you to do these sort of things in browser in a way that I think would be very advantageous for what we're trying to do imagine hey I click on a link I don't have that link I'm gonna somehow know to know how to address the IPFS and then download it in that moment using WebTorrent and then sync it to my local github repo with a github login or something like that Yeah I believe WebTorrent is how is one of the ways peer2 works it's like a very solid piece of work and the protocol is established I'm pretty sure it's in all the major browsers now so it has the advantage being that you have to download an additional thing for I think Doster is like really cool conceptually right the idea of being a truly the truly decentralized communications approach but I don't know if I can see how well it would work for something like well for something that's not a messaging process you know I mean the sort of cool idea that I like from Doster is intended to be slow right which I think is very desirable for our stuff the idea that you can queue a message at one point and send it much later and the protocol anticipates that sort of flow because it means you don't need to have an always on server you don't need to have always a connection to the internet and that I think is really potentially very useful especially because so many of our projects are static sites that either aren't or don't need to be on a persistent server so it would be interesting to think about how these things adhere together I agree so I am very interested in these and all tools right in this space I wonder if like you're going back I guess a few threads one is like keep thinking of your podcasts Jerry and have you say you know like you were going out for like topics and so on and you know also going back to the tools for thought process and so on where it's run while running and maybe we could imagine having like sessions called out for like you know we share about like a particular tool and then we know we could imagine having like a call out for a community saying like if you like this tool or would like to learn more about this tool then we meet and see you know how we could use this tool together as a rule for some purpose just as a pragmatic idea I don't know if this makes sense but beyond that I guess maybe I'm stuck in the past but I am still like sort of like feeling that you know in my mind I guess I've also been working on that for two years now and I see his mutations clearly but I sort of feel like to some extent we haven't probably like maxed out opportunities of like just agreeing on his repositories and like you know iterating those except of course like you said very rightly whenever two people really want to collaborate real time on the same resource but the way I guess I was thinking of the architecture of that which is what I tried like doing with Facebook and so on is you can even mark or special case those say this is actually for active collaboration and then you sort of like by agreement or convention you use an intermediary tool that lets you like see how it activates for example that lets you work concurrently just to get as the actual more like longer term source of truth so this is exactly how the hedgehog in the Iwara works you have hedgehog like every minute a script runs and dumps old pages to eat and the source of truth that the Iwara reads is still get a marathon so to some extent I guess in my mind it is like this you know like repository with resources or many and some of them we say I actually don't edit this one but you can use it and then you can directly use this proxy and at that level you can say what we could have like proxy tools for diagrams and visual thinking essentially like we can have you could imagine having like a recommender tool for thought or editing process for individual files coming from the map and so on so essentially I will take this layer approach also considering that it is already compatible with Masiwiki and the Iwara not to say that there is no like there isn't like a better long-term approach but this seems to be quite solid Pete got a bunch of us using HackMD which is HedgeDoc and we were doing that I was having trouble mentally spinning up Hedge sort of HackMD pages and understanding where they were and when they were going any place like the back end of it was kind of beyond my kin and was confusing me and collaboratively editing in HedgeDoc was okay but not nearly as simple and smooth as Google Docs which is just so damned obvious and simple but works and if you've got a script that's automatically doing the push that's cool and eliminates the problem I just described then you have to sort of keep in mind that you're sort of working with interim versions of different documents as they float around a little bit but if you can get past that and work kind of slowly and carefully then HedgeDoc winds up solving the concurrent writing problem but you need to know you need to have some way of saying hey there's a HedgeDoc open on this you know if you were about to come in and edit this page right now there's a couple of people off there working on HedgeDoc who have been pushing to it so maybe the script would also for example aside from pushing the occasional version to the canonical version that's living on GitHub or wherever maybe you could also put a flag on the page for anybody else coming in to edit during the moment where people are collaboratively editing it which feels like a whole bunch of workarounds reaching behind your back to get things done but could solve the problem temporarily I agree I agree too basically I wanted to relate an experience that we had when we were trying sync thing um sync thing would kind of like get except without the commit stuff you know it just works in the background the funny thing that we found was that it actually syncs fast enough to be almost real time so it's not as real time as HedgeDoc but if you can slow down a little bit from HedgeDoc and if you're paying attention who's editing who's doing most of the editing sync thing was actually working like a real time editor for us so I don't know what that tells us but yeah and there are like ways to speed it up too like depending on how you set up doing it automatically um and not like not relying on a tool I almost feel like collaborative editing I think HedgeDoc is really good for collaborative editing and I think that's a really useful thing to have on hand for stuff like this and you know that sort of thing but I don't necessarily think it really solves the problem we're wanting to solve which is like if we we want separate sites that can link to and pull down from each other whether they're produced by HedgeDoc or not is not really useful right and if you think about collaboration how it works in practice of course we can for some like the emitting notes it's like we're clearly like thinking right now so it makes sense to say like oh we need something with a time collaborator but like most collaboration I think on the internet ends up have most like reading and writing and so on ends up being a synchronous to some extent which is why I sort of feel like maybe we are focusing on this because it's a technical a cool thing about programming of course and like it does get us something unique but it doesn't seem like it will apply to most cases we will need to model first which will be more like opportunistic cross linking I think Jerry? Then I'm just going to put another smelly fish on the table which is then we also get into this question of vaults versus repos versus namespaces versus wikis whatever which confuses me also and is a thorn in my side because partly because of the quirkiness of tools like obsidian which don't carry over their traits and features across vaults but partly also because man what is my space, what is your space and where did I put something and that needs to be really that needs to be pretty transparent pretty simple and the defining of boundaries around namespace I find to be important and interesting and useful for communities of practice because when you're linking richly inside of a namespace and creating what we think of as maybe a traditional wiki that's really powerful and that works really beautifully and so how to preserve that while masking or hiding the complexity of that is a companion problem to the how do I get a distributed document repository or layer that does versioning and we've spent a whole bunch of time in free terry's brain and these calls and others like kicking these things around in different ways go ahead Aram yeah I'm curious how exactly does the because I've seen you do this in some of your notes Fonsi and how does the push feature work in Aurora yeah so push is just like an experiment in like transcription at a distance essentially so when you say push you pass it like a node which you can think of as a topic or no it's just a weakening and then whatever is under that in a scope so for example like in dental under so you know that will actually show up remotely so if you say for example like yeah here I said push Noster because I thought the discussion was very interesting that means that whatever you write here will show up in the Noster context so it's like writing in two places at once and how it works is it just passes for it looks for pushes and passes them and then just they show up as a virtual files remotely not to be too pragmatic not to be too pragmatic but how would I overlap my brain's links for fellowship of the link calls I've got a link to the hedge doc which has our shared notes that's done I have a link to your Agra for fellowship of the link in my brain but that's not really sort of the shared notes so much so if you have a node called fellowship of the link it will show up in fellowship of the link in the hour so that's the basic like you know coordination like very basic but you know what we have as a coordination I guess tool so but in essence whenever you can name something it will show up in those context and then if you you can pull or push and in general if you don't do it in the Agra you won't see the effect but the Agra will see your pulls and pushes and it will essentially like transclude content whenever it shows one of the resources or whenever you push to something in a node in the Agra so it seems like one of the optional but good to have features here is the pulling and pushing which is the updating of the remote nodes system with something that was just changed that is being watched or noted in the local system right and I'm being very clumsy about how I'm saying that because I'm not trying to understand what transclusion exactly means etc etc right right no no this is essentially I know if you how far it will go but you know what can you write anywhere in principle but in particular you need to thought that the Agra can interpret and like do something useful about for you so a pulling or a push will be like a source or some sort of like active link to put it some way where you're all giving a hint for like actually if you can do more right so you know pushing could be used for notifying you know what I do sometimes of course it also works in the Agra, you have to read it there for now but like you can take a note anywhere and say like push, finish or delete and it will show up in our in our mode for when we want to like you know discuss later and there's a few like this and it has to do with like sort of like trying to define the minimum set of cooperation like devices to hint at you know future in danger I wanted to come back to messages versus documents because Ram said something really interesting you know not sure it's great for messages but but if so my observation kind of is if you have files the size of massive wiki pages you can just make the whole thing one message so you can use you can have documents but use the messaging to transmit them I guess so then the other choice would be you know here's the first version of it and then I'll send you changes via messages which is you know kind of kind of what CRDT does I think the main thing like you couldn't just set up like a network of these and have them collaborate collaboratively create a wiki through NOSTER or how it's pronounced by itself there needs to be some additional layer coordinating with it yeah and maybe this was before you got on I think of that as the versioning layer actually how do you manage the fact that you know I've got a copy of the file and you've got a copy of the file and you've got changes in them so again I was saying that's get the solution for that is get basically yeah I think that's interesting I think like the other piece of the problem is like like I said one of the advantages of NOSTER from the perspective of what it's accomplishing to do is it's desynchronousness so I anticipate that because it's not partized speed we really did get a bunch of us trying to send messages to each other in order to write something collaboratively we're going to get syncing issues or like collision issues really quickly NOSTER isn't fast enough to do real-time editing but it's fast enough to do async collaboration I think on wiki pages yeah but what I'm saying is like it's even like it's not even fast enough to guarantee that the version you're working on is necessarily the version that is the up-to-date version because it doesn't prioritize getting messages to each other quickly it just prioritizes them getting there eventually which is really important for what's trying to do but what we're trying to do you can very easily see four of us working on a wiki I put up a change it syncs to Flancian's version Jerry makes an edit syncs that to Flancian's version and then you make an edit to the version that I had right and now there's a collision and now we have to do a merge fix which is going to be a difficult thing to manage and there's two kinds of problems one of those is out of orderness it has no desire to maintain order that's why I'm so hesitant to use it for this particular thing it's totally fair when we're thinking about what the platform has prioritized Noster is intentionally not prioritizing those things because it's designed I don't know if you read the story but the guy who designed it lives on a sailboat and only can power our Raspberry Pi to send Noster messages right so like the protocol is not designed to be fast it doesn't want to be fast and I'm always very hesitant to use systems against their design intention because I feel like it's a good way to run into problems brief historic story which you just reminded me of which is I wrote about general magic in their form magic cap and telescope way back in the day and it was fascinating because they were hot super sexy start up had this vision for what it was going to be they were secret for a really long time they launched and went up about 40 feet and then like plowed into the dirt like a couple feet later because they had a $400 email machine where magic cap the UI which was done by Andy Hertzfeld who should have been famous basically was a little prison of a desktop with no ability to really do anything interesting with it I used it and I'm like what the hell did he just build it had a drawer where you could put things in a little desktop and it was like terrible and then Jim White who had been part of the X400, X500 teams was sort of trying to make up for the flaws of X400, X500 by designing Telescript which was a message passing protocol at the moment when the web suddenly gets hot and it cannot emulate the web, it cannot do documents and again I'm out of my technical depth now but he had basically designed a dead end architecture of the wrong style at the moment where the opposite architecture was eating the world and so those two reasons plus costs plus a bunch of other stuff I think the reasons why general magic just fizzled immediately but there were brilliant designers on deck who wrote clean like green field software with the best of intentions and all of that and to me that story has really stayed with me for a long time it's like ooh just because you've got famous coders on duty working hard with a mandate to do green field work doesn't mean they're going to do anything that is actually suitable to the moment sorry for the long time I mean that's like the whole story crypto currency projects right there lots of all stars not a lot of successful products so do we have conclusions here? do we have experiments we want to set up? Pete are you going to try a couple of different experiments further and share back through a sharing system? I think we should do I think we should go down the markdown get path I think that's the next one I'm happy to stick for now with markdown get on get hub and that doesn't bleed my brain so badly that I need to somehow like compensate for it it may be that the next it may be yeah it may be that the next moves are actually kind of trying to figure out the subset of get stuff or making it easy enough or something I don't know cool Aram go ahead yeah I think it seems to me that what is needed is sort of like a predictable path on a site for discovery of content and once that's in place it becomes easier for us to try to do a bunch of things a predictable path on a site for discovery and the second thing would be a predictable format for the content then if Peter want to try communicating with a site taking it up through Nostra and I want to try IPFS and Flansy wants to try something else entirely like that would all work in parallel I just a good example of this for example on Agora when I see a multi-word page that's got dashes or at least the ones that I'm pulling up when I look at Peter's wiki it's got underlines for the thing we've already made it harder for the predictability problem both should work that's good to know and then the second problem is how do I pull the content off so much of my time is spent parsing to find the actual content so making it so that I can push so that I can do the pull process so I could it would take me like 20 minutes to write a rule that says okay whenever I go and mark down and I double bracket and let me see if it's on my own site and if it's not on my own site go pull the page from somewhere else and as long as I know what the format is I can get the appropriate content so that's the other part of it and it doesn't have to be the format of the page we could do it in JSON-LD we could have an API whatever way we want to do it I think is fine as long as we decide on a consistent way I'm fine with a lot of different ways I just you know