From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id eEKiL6mAwl+tTwAA0tVLHw (envelope-from ) for ; Sat, 28 Nov 2020 16:54:01 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id +JqMK6mAwl/0KQAAB5/wlQ (envelope-from ) for ; Sat, 28 Nov 2020 16:54:01 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 24D989403D3 for ; Sat, 28 Nov 2020 16:54:01 +0000 (UTC) Received: from localhost ([::1]:45886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kj3DD-0006Mo-1x for larch@yhetil.org; Sat, 28 Nov 2020 11:36:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:32944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj3AQ-0006Mb-L1 for emacs-orgmode@gnu.org; Sat, 28 Nov 2020 11:33:46 -0500 Received: from mout-xforward.gmx.net ([82.165.159.12]:41271) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj3AO-0005E7-4B for emacs-orgmode@gnu.org; Sat, 28 Nov 2020 11:33:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1606581191; bh=hQOO7YfX97VOFaYGiErxeZhZboOKS5xbdtSFnwWiN0s=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=OckIF2DWJt8or9YdWu1EEdEc5NhbFdpt/3bmCg3hpJgPQK8k6NMpLbDQ7aGfmPE1u FvfM+kdqJmNXK3P5nfFCnYG1fS6y4I1sMZw/ag94KEsrq8ba14EuNlFP0h3M12uH5l DzfFvnBJV9s3gNinH13fe5lLe9dsK1fBtefswKJM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [213.165.168.94] ([213.165.168.94]) by web-mail.gmx.net (3c-app-mailcom-bs12.server.lan [172.19.170.180]) (via HTTP); Sat, 28 Nov 2020 17:33:11 +0100 MIME-Version: 1.0 Message-ID: From: Christopher Dimech To: Jean Louis Subject: Re: One vs many directories Content-Type: text/plain; charset=UTF-8 Date: Sat, 28 Nov 2020 17:33:11 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: <878sauhhv1.fsf@web.de> <875z5ygwwr.fsf@web.de> <87r1olfvh4.fsf@web.de> <87wnybb340.fsf@localhost> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:RSTA2P3wfV++rJMYK9Y1ZeYK75qKMFeWqz/0+dxXrUsSnBKOw1LGf7F5CBi7mqrpRXBjj EVPlLz0zhTSbw4iOKBwex6eLOBAM698BkE8jGFAvi/B82FtWIBtnU8dBVYq3KLqNf9aF/GNnGGLr 3Jj2jdjLYl9dE4h8vmmSr48vcawd062iQ/G6T+AGZzHnc8gBPXMFY2IqVs2hDm8AfbXUvtvU0Sn6 vrDIBcmN/Sir6MfnY15ogWqtHaGkxrkjPBbub9tnsBOaFeV8NkRmMx2P16/rPGRq3DtEqNHHM9Op No= X-UI-Out-Filterresults: junk:10;V03:K0:5JqmlFHLYE4=:rc6InSzbzOSqpRf+VKY3+lJQ SIxtkXdjVyuil1LAnHiyrkXnaM9hA6gYyt0ug7rKiuAHbt2H/O7gevDkpxlbcvefTuHH2EbtY sse5/j1tkyUGcDndei8Devnma3i0ezgx1ijFmdOHD1XSTMWA6jxRY+vPiVLWu2IoEf0H5p1mC YkYlgPkaU0D1IZ00dES1XUx/StLmpS99/00SoEQoN366gvel9/n2p9e2U07EuJpgxyrqHuaBm UPt3gU/Mz0JdneXOz3pVbUXfKvY+MoZlRxT+7laDqLOE4PO2IkHURPRttDT8Wh5A6BL+6tJlK BbPFnbJt8uj/RnS3vklRbGDPJVws3lcK97cUtaStySmplMfuVtywRXJKA3Y9cJPtaX8pLS4SX B9LQatTNRb0vexMqpZ+km+3GIJqef8wpTCTAZJhIiwf3S2NdGFN/UbxuFuu2RllX+Oacfk8yc y+MXJPOj1iE/7BotxSJnApaYngC1BYxIPzV//C2Oua3XRMy3Rh9kBF5dlZnljK6SPkR9YCcTR NK308RzyFYp58DuXdBV3fmViljDZ3zlq4bq2PCKa1/Is2CDK8+Tt+tRgtpgQQp5L/uoL++KLJ wzqTMpz5Kafq0OpbYWARXHvuiVNzfdQkNXRxIAZ6KNxgrh0JGo6DpgXAsLT3Yrin/Ol4EcwEV ZQ= Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=82.165.159.12; envelope-from=dimech@gmx.com; helo=mout-xforward.gmx.net X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L5=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Dr. Arne Babenhauserheide" , Texas Cyberthal , "emacs-orgmode@gnu.org" , Ihor Radchenko Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: 5.73 X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmx.net header.s=badeba3b8450 header.b=OckIF2DW; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-TUID: JnzRv5j9/dBk > Sent: Saturday, November 28, 2020 at 5:16 PM > From: "Jean Louis" > To: "Ihor Radchenko" > Cc: "Dr. Arne Babenhauserheide" , "Texas Cyberthal" , "emacs-orgmode@gnu.org" > Subject: Re: One vs many directories > > * Ihor Radchenko [2020-11-24 10:57]: > > > I find it entertaining for now. Now, what is exomind? > > > > Unless I misunderstood, Jean referred to "external brain" concept: > > - https://beepb00p.xyz/exobrain/ > > The more you send me reference more I discover other set of people > doing same what I am doing. Since I have implemented central meta > level organization it is moving rapidly, everthing gets sorted. It > develops by itself and is rapidly accessible. Believing that only you think a certain way is a big mistake. > That website I have to mirror locally to pick ideas and learn from > others. Mirroring I do with: > > $ wget -Emk http://example.com > > As that command replaces all hyperlinks to local hyperlinks. That > person advanced in organization of things. I stick to few principles > and just design it by principles. > > Design works rapidly. Few Emacs Lisp functions and access to reports > listed in Emacs Buffers and integration with other tools. > > With one function and one PostgreSQL table defined in 3 minutes I get > rudimentary backup and version system for any column values that I am > editing in the database. If I edit note, the note is versioned > (previous version stored) before I start editing it. Principles I am > following are basics what programmers like, to minimize or eliminate > repetitions and efforts to achieve the goal. > > Person above have extracted or exported its own database of hyperlinks > to hyperdocuments. My side I have made for now Org export of any > subtree or the whole dynamic knowledge repository. There are many > things to go. In Emacs development version all kinds of hyperlinks can > get their handlers like gopher:// gemini:// message: tel: sms: and > htat will be very helpful. > > No, I do not use "exobrain" as a term. I rather lean on Engelbart's > terminology and follow his principles as we are very late to implement > what was envisioned back in 1968 and before. It is 52 years already. > > And many more years since Memex has been invented: > > Memex > https://en.wikipedia.org/wiki/Memex > > As author said: "The memex device as described by Bush "would use > microfilm storage, dry photography, and analog computing to give > postwar scholars access to a huge, indexed repository of knowledge any > section of which could be called up with a few keystrokes." > > And that is exactly what I am creating here to have anything called up > with few keystrokes and to be able to share files with individuals or > groups of people without more thinking but just designated what to be > done. > > Have group of 5 people to share notes with? Just find the designated > group and click share. Computer would handle the rest, maybe send > files by emails individually, maybe inform people by SMS, maybe upload > files and share password protected hyperlinks with those people. > > Integration is another keyword I like to follow. Android principle of > sharing is pretty much based on integration. We have all the small > functions around us only not well integrated with their relations that > concern human problems. > > We have files on file system which we cannot easily share with groups > or people we want. Address books are all sparse, one is in this email > client, one is separate, one is on the mobile device, another email > client does not synchronize, and so on. I have forgotten this long > ago and use central address book from where everything derive: > > - no Google, clouds, etc. that is very insecure. Do not give contacts > to Google, there are hundreds of thousands of staff members there > and no guarantee whatsoever that they will not read it. > > - keeping contacts on my computers. I have already spent money for > hard disk, there is enough space > > - exporting contacts from central database and importing to email > clients, mobile devices, this way everything is synchronized. > > How quickly can GNU/Linux user share a file with somebody? > > - locate the file by using hierarchical browsing. If file system is a > mess, this alone may take some time > > - open up email reader > > - find that email address. If it is in the email reader already it is > good. But it could be in the phone. It could be on paper, or on > business card. Where is it? Maybe calling person? But where is the > phone number? On first phone, second phone... if all is synchronized > maybe is easier to find. > > - attach the file > > - send the file. > > But then sending SMS or calling in the same time does not > work. The above process is not well integrated. > > It could work like this: > > - user just thinks of what has to be shared with other person, types > the terms related to the thought > > - locates the file and press share > > - locates the user and press enter. FINISHED > > That would be better integration. Even better it would be if user can > choose the automated workflow option: > > 1. send the file, automatically record that file has been sent to > specific user. Tell user automatically how many files are attached > and attach annotation belonging to the file as body of the email or > any instructions. > > 2. in the same time inform the user by SMS that file has been sent and > record that SMS have been sent. Software like kdeconnect, gnokii > can be used for it. > > 3. within 1 hour, or other period of time, computer asks to initiate > the call to the user to follow up about the file sent and maybe > nudges few times and records the action. Software like termux tools > can be used for it. > > My first big surprise with Org was that there was no possibility to > assign the task to other person and send that task! I actually could > not believe that it was meant for single person or personal tasks and > notes. Then I made the function to share the task quickly to any > person assigned to the task. If person is assigned, task is sent to > the person. If no person is assigned then I choose to which person to > send it. This includes also groups of people. > > > - https://zettelkasten.de/posts/extend-your-mind-and-memory-with-a-zet= telkasten/ > > That is similar idea of organizing. There is claim that one shall > forget about categories and rather use tags. I think that using any > types of attributes is better and using more attributes helps in > quicker location. > > > - https://github.com/novoid/Memacs > > I have installed it and not yet used it. I would not like having too > many tools on file system to manage information. There are too many > memacs tools made for console. In general I am tracking all SMS sent > from phones to other people, they are automatically inserted into > corresponding people's objects. Then I know which people received > what. Phone calls can be tracked too. Phone calls can be > recorded. Sales and marketing departments need that. I am using now > only principles from Memacs and implement some of them in Emacs > Lisp. As I like integration I do not like external tools, but the > dynanic knowledge repository must be usable externally without > Emacs. > > That becomes very easy by expanding the whole tree of notes into the > file system from time to time and generating meanings for symlinks > that point to fixed locations on file system. > > The centralized subtrees or nodes of my dynamic knowledge repository > can be moved easily from one parent node to other parent node. This is > because human must sort things properly. But if such are pointing to > files on file system those files never change. Meaning and relations > can change but file location should not change. Directories are more > static then files. They would never change. Files if not indexed but > located in the archive could maybe change or get updated. > > Git repository could get updated but its directory need never change > in the future. > > Let us say there are many PDFs to be indexed and accessed through > semantics. The PDF file name could change but access to PDF file need > never change. Renaming PDF file need not change access to PDF file in > other word there is no need to rename it twice, it can remain in the > database and get accessed automatically. But that requires directory > to be static, or it requires md5sum of the file to be > static. Something must be static that file can be found by the > system. Best is when file is under specific unique ID that never > changes. Then everything becomes unique and clear. And symlink can be > automatically generated: > > ~/hyperscope/1/2/3/432.pdf would be file > > ~/hyperscope/1/2/3/Knowledge.pdf would be symlink to 432.pdf > automatically generated and from time to time updated if there were > many changes in the database. > > The Org hyperlink to the file could point to: > ~/hyperscope/1/2/3/432.pdf because file location is this way static > and will never change. > > But the Org hyperlink could as well point to meta level hyperlink > (hyperscope 432) as that would open the file no matter where is the > location. > > And if file is on remote server, something like > > [[PDF File][(hyperscope 432 2)]] > > would then work quite well. As this type of dynamic knowledge > repository is multi user automatically as database is multi user. It > means files can be accessed from all over the world and groupware > collaboration becomes trivial as PostgreSQL is networked database. > > Now for the user accessing the specific database then the hyperlink > can be just (hyperscope 432) and user who is remote could say by > activating the hyperlink that remote user likes to have the > file. > > Program must know if user is local or remote. If user is remote the > file can be sent by email, it could be automatically encrypted and > sent, encrypted and uploaded to web server, or uploaded to web server > with password encrypted access or without. Any information can be > protected and not all information need to be shown on public > webservers. > > Maybe it becomes better to use the URI like: > hyperscope://user@example.com:432 > > whereby 432 would not indicate the database port but rather the ID of > the hyperdocument to be activated or accessed. user@example.com would > have relation to the actual username, password, hostname, database > name and port on the user's own system and program installed as such > without local database. Maybe port could be optional as multiple ports > could be on the same hostname. > > That would create unique access to specific domain and specific user > on remote hyperscope server. It becomes possible to securely share and > access files or do any action on such files by using the groupware > features. > > The big difference with the WWW is that system is structured and > offers liberty on how to access files and what to do with the system. > > User may remotely invoke emails to be sent to groups of people. This > is not what WWW offers by default. > > User could remotely edit Org file only by using the database. Org file > need not be located on the file system. And yet such Org file can be > automatically saved on the file system or sent to other people. > > Locating 4-5 or more people becomes possible, marking of them and > quick export to Org file becomes possible. Then user may invoke > further actions such as visiting people, negotiating, calling people, > sending them information by post, sending SMS to people. > > When backed up by well networked database it becomes multi user > collaborative meta level Org system. > > > - https://blog.jethro.dev/posts/org_mode_workflow_preview/ > > I have captured that one for later research. Small details and notes > do matter when creating some new useful features. > > Jean > >