Update 1: Changed the title as the concepts grew, as I edited this post, plus I added a proposal for all of us to think about how to improve the flow between the core of our knowledge (sitting in Logseq) and the World Wide Web. But I’ve placed that call for action under the broader topic of Logseq’s relationship with Web (including the technical aspects and standards) as a whole. A relationship that is a bit at risk due to lack of clarity on how subdirs, for instance are mapped to filesystem and URLs by extension.
Note: since the title changed compared to the original post, I hope the following still makes sense (i think it does if you are a teacher who is also a reader otherwise don’t bother). But I will reveal the original title all the way at the end of this post so you would have access to it, if you needed it. But I also didn’t want to cloud your judgement with the original title.
Start of the original post
I love Logseq and am basing my work and art off of it. But as a lifestyle, I avoid synchronous communication, mainly because of my job and the fact that I need to focus all the time, which ironically is why Logseq is practically my digital self now. I have put a lot of time in promoting Logseq and writing about it and when I publish my website (using Logseq), you will see what I’m building. But okay, it takes time to get there. When you create, you take about a year to gain mastery of an art before producing.
In this journey I have started with Logseq, I am sacrificing a lot in my personal life (alienated friends and family members but nothing I cannot manage to take care of). So I expect a minimum responsiveness by the makers of this amazing piece of software. I wouldn’t have asked, if it weren’t Logseq’s dev model. But it is. It is open source and free software (okay maybe not GPL but it’s free as an eagle)
So, teach me how to get a minimum response to my posts here, so I can try and be more effective.
For the record, I am convinced that Logseq is the NEW BROWSER (at least) for knowledge artists that get to know about it. Or those with the right side of their brain, a tad more active that the rest of their existence. This is also why, I love bringing people to Logseq. In fact, I’m building educational material that my students (who are also teachers) will have to practice using Logseq. I find this normal to collaborate this way, because you guys have clearly built the foundation for this type of open collaboration, which in and of itself is a beautiful phenomenon and I am greatly thankful for.
Still, I feel alone in this community (is everyone on Discord? or…?), which actually does seem to have the right architecture to scale as well. It’s clearly carefully implemented and has good design. So not sure why people don’t visit it more often. Maybe it’s because their browser is not integrated into Logseq all that well. I don’t know. I’m just sharing candidly here.
Inevitably, standards will start to emerge within the Logseq community, which could be the basis for nuanced communication between agents (say, public graphs exchanging minimum semantics).
We have one discussion here, on public graph discovery but the focus is too technical and is moving away from Logseq’s strength, which is fast creation and communication of structured and connected data (among other things of course, almost flawless even).
The Middleware for a Person (and Logseq arch is key here and does allow it)
For instance I see Logseq, potentially as my ultimate personal middleware (personal ESB, personal service bus, that doesn’t work does it?)
As a species, we have learned (through the great Sapiens before us) that whenever we need integrations, we need some kind of middleware, or an integration hub. That’s why you have these Apple Home types of products that bring things together using one hub.
Or in the data business where I come from, a big chunk of budget goes into some form of ETL, data warehousing, or ESB or data virtualisation work. Well, Logseq can be that for a person. For a mere mortal. I mean, if you put the power of the Web and Unix and experience from your knowledge graph, what else do you need?
And there’s no middleware more powerful than Unix’s legacy
Nowadays sitting on commodity hardware, in highest qualities, the new MacBook Air, however much it looks more like a Pro, does propose a good basis for a commoditised and stable Unix-backed platform to create and automate at levels that have not yet been seen. The creation of a new platform to unify the power of Unix and the Web is long overdue. But I’m an optimist (by virtue of being an entrepreneur) in thinking that we have a viable way out on our way something that will surpass all of us.
Logseq, believe it or not, can effectively bring Unix and Web together in a single spot (at least for me and people like me, I guess). Issues with Unix and command line are
-
disconnect from Web (HTML/CSS/JS platform),
- which is the result of 30 years of standard building, which had many parallel runs in the past around XML and the browser wars, quite mismanaged.
- But the baby is now grown. It is now mature enough to jump to the next level,
- The semantic web or as Sir Tim calls it Web 3.0 and how furious now, he is with Web3.
- There we had some backs and forths as well but I honestly think with JSON-LD and OWL2 fed through the Linked Data Fragments #LDF protocol as opposed to the hard-to-author-by hand RDF over some viable social transport Twitter-like, we should be good to go.
-
Space in paths. No Unix hacker wants spaces anywhere near their files and it’s by design. But as knowledge artists, we like spaces don’t we? I mean, I do. They help with legibility immensely. Space is key in typography for typography lovers.
Logseq hides that issue (lack of space) in the command line because people like spaces and don’t want to be stuck in the command line box all the time either, but this immersive experience with the Unix legacy requires subdirs for instance.
Logseq also has a natural connection to the Web, it might even be able to manage the full lifecycle of a data product using Linked Data Fragments, for instance but this one requires great thinking and actually the designers of this will have to have synchronous communication as in they must be in the same room for at least two days to hash things out.
A proposal for integrating the Web experience into Logseq as a food for thought.
#meta I thought this proposal slightly after my original post, which also led to a change of title as I realised how quickly the conversation turned around, as I grew my post, which by the way could only happen in async type of communication, strengthening the subject of my original lament.
Logseq is the context that leads to Web
I like how {video <URL>} empowers me. I do.
It allows me to take the video, and annotate it effectively and efficiently.
Why shouldn’t that experience be replicated for clean Web pages, think Wikipedia, think websites built by those who had understood the original purpose of hypertext. Web has had a few rough times over its three decades of history. But AJAX took us to an extreme that we are now coming back from. Look at HTML over the Wire types of architectures pioneered by the makers of HEY.com, Basecamp, and RubyOnRails. Brilliant individuals.
We no longer have the thirst to show a lot of stuff to the user thank universe. Client piling up XMLHTTPRequest()s. I mean, it was fun. But HEY shows us, as JIRA/Trello do or of course Logseq itself or the many other applications that use Web for what it is. Here’s one example to illustrate the HTML over the Wire principle. Please bear in mind, I’m not locking anyone into one way of thinking but I am pointing to literature that helps shed light on some of the nuances in my arguments.
HTML over the Wire, the way I understand it, is: You let the backend control the frontend as much as possible and limit the complexity of the frontend. It’s good for code maintenance, scalability, caching, UI flow, in fact. When the backend controls the flow of one context to another, you application is automatically mobile-ready because at the end of the day, many digital products boil down to a loose orchestration of the flow from one screen to another with the same or different set of templates.
One of the advantages of these kinds of app is their lightness on the browser. Here’s one evidence I try to borrow from history of software.
HEY/Gmail (or any single-page webapp really)
Before HEY, I would never would have wanted to have multiple tabs of Gmail open for instance. Because Gmail, although changed now, was actually born as one of the early serious applications that implemented AJAX and still haven’t recovered from it, although, if you look at Gmail, you see a lot more simplicity implemented in it, than before. If you take their latest version, they have completely improved the experience though, kudos to their good engineers/artists.
Many other websites have actually quite simplified now. React and similar types of frameworks have also done a good job of simplifying web development, which are all good moves in the industry so I hope this post is taken as a token of optimism for it is upon us to define the future, even if the times are difficult these days for many, and especially because of that. While we’re on UI technologies, I should say that it hurts to poorly structured code running all around the Web. GraphQL did a good job of calming things down. But I understand it has limitations. Imagine you could safely generate REST via GraphQL and SQL via Malloy (great initiative by former Looker employee), for instance, which are semantic-aware low level code generating pieces of technology, we might need to get out of this world of differences and as an industry thinking of simplifying to accelerate, a phrase I learned from my one and only CEO, Felix of Collibra, first of his name.
Anyway, when you consider all this, what would it mean to interact with the web context, starting from Logseq. Would it be a form of iFrame with some basic overlay or control from Logseq? Fullscreen like a video is helpful. Open in Browser is helpful. Back button is helpful. Bookmarking. What you see on Safari on an iPhone or Chrome in fact, but mostly the phone version. It seems to me that the engine behind Logseq is Chromium but I might be wrong because it wasn’t that easy for me to figure it out. But I opened the Developer Tools with the usual set of keystrokes and it looked like Chrome.
Maybe there are other ways to invoke a browsing context. Maybe lower level because Logseq, after all has to be deployed as an application anyway to maintain its promise of privacy-first, which in all honesty is the only reason I’m considering it as the platform for some of my product features.
So, what if I could somehow use Logseq as the secret door to the Narnia land, being the World Wide Web. With Unix as my army of interconnected little robots called commands.
So, if we believe, even a bit, that Logseq is building standards. Then we will also know that:
Standards don’t get built over synchronous communication. Engineering (and some other types of art) mean spec and executable models. Those are hard to build over synchronous communication and hardly referential fragments (which is what Discord is) In fact, I would even go so far as arguing that Discord is against the values Logseq promotes. But okay, everyone is free to choose for themselves.
Reading long texts is also entailed by your possible belief in the fact that Logseq is a standard setter.
Here’s a twist to all of this. This very article, however long and boring, which you may or may not have chosen to read, would not have been possible to create if I had started this discussion on Discord. I kept editing it after my initial two paragraph or so post. And this is the model Stack Overflow used to build the Wikipedia of meaningful code fragments (I’m not sure how they’re doing now but they were good before)
Annotated title of the original post:
Can a person be a member of (the/a) community (these days), without being on Discord? (or any synchronous communication channel)
which I changed because it sounded a bit too needy.