Show HN: Contacts: A Microlang for Managing Contacts(scroll.pub)
scroll.pub
Show HN: Contacts: A Microlang for Managing Contacts
https://scroll.pub/blog/contacts.html
13 comments
Looking at vCard (https://pldb.io/concepts/vcard.html) it would be straightforward to compile Contacts to vCard.
I am not the one to do that due to time constraints, but a company in the space did reach out to me and they are interested in leading a new standard based on this. I offer to anyone the same I offer to them: I can create better documentation on how to write more advanced Parsers, so that it should be easy for someone who wants to make this compile to vCard do.
We would just need to add a `buildVcard` parser to Scroll, and then the appropriate parsers to compile each field to vCard format.
Multiple phones/emails/work/personal et cetera are trivial in this system. Check out PLDB which runs on the same system and has almost 400 fields of all types (nested, multiples, lists, blobs, maps, et cetera)
Everything is public domain. It is also open source in that the source code is available as well. I added that because otherwise I could make the binaries public domain without publishing the source code.
I am not the one to do that due to time constraints, but a company in the space did reach out to me and they are interested in leading a new standard based on this. I offer to anyone the same I offer to them: I can create better documentation on how to write more advanced Parsers, so that it should be easy for someone who wants to make this compile to vCard do.
We would just need to add a `buildVcard` parser to Scroll, and then the appropriate parsers to compile each field to vCard format.
Multiple phones/emails/work/personal et cetera are trivial in this system. Check out PLDB which runs on the same system and has almost 400 fields of all types (nested, multiples, lists, blobs, maps, et cetera)
Everything is public domain. It is also open source in that the source code is available as well. I added that because otherwise I could make the binaries public domain without publishing the source code.
i think this is lovely … one idea would be to build a raku Grammar for your language (which would be also ~23 lines I suppose) … that way you could make raku Contact objects and easily add international variations. also you could write an export (ie print) method to output from Contacts to your language. disclaimer : I wrote the raku Contact module https://raku.land/zef:librasteve/Contact and would be happy to help.
https://docs.raku.org/language/grammars
https://docs.raku.org/language/grammars
gnud(1)
[deleted]
For ideas, personally I manage my contacts in two separate entities because I still have to find a way to merge two different worlds:
- on desktop my contacts are org-mode notes, in contacts terms I use them just for email completion in notmuch (my mail client) but the contacts notes contains much more, clickable links to some relevant conversations, TODOs digested also by org-agenda etc etc etc a simple pure text feature-rich CRM;
- on mobile https://github.com/tchapi/davis on my home server and DavX⁵ on Android, I have no integrations and well, I still do not need it much except to add new contacts or delete them in a single place for both.
The above description to state a thing: the BIG issue with all modern software and in part unix classic one is integration. In Emacs anything is integrated so there are not much boundaries between functionalities as we have not much boundaries between things in our mind, while on modern systems at maximum we can copypaste or drag&drop and in Unix we can combine but every time we need to mangle text since there is no common language for anything, what we use is the shell, not "the system" witch is written in a separate compiled language. We can't circumvent this limit with all modern systems. That's is.
So despite the idea of simply storing contacts with a tool that allow easy export in various format might be effective in some cases we will anyway hit an integration wall sooner or later, let's say another app who need another kind of export and so on and the simple language became more complex while still remain unable to add anything else on top/related to contacts details do to "app separation" bound to the system design. It's a nice effort, and I thank the author for sharing the code, it might be helpful for some only we need a different software architecture to really manage our digital life, one we abandoned decades ago, the concept of an OS as a single application/framework where anything is runtime editable code, user-programmable, a single language, so we can just access functionalities via common data structure and functions instead of the integration hell we know very well.
- on desktop my contacts are org-mode notes, in contacts terms I use them just for email completion in notmuch (my mail client) but the contacts notes contains much more, clickable links to some relevant conversations, TODOs digested also by org-agenda etc etc etc a simple pure text feature-rich CRM;
- on mobile https://github.com/tchapi/davis on my home server and DavX⁵ on Android, I have no integrations and well, I still do not need it much except to add new contacts or delete them in a single place for both.
The above description to state a thing: the BIG issue with all modern software and in part unix classic one is integration. In Emacs anything is integrated so there are not much boundaries between functionalities as we have not much boundaries between things in our mind, while on modern systems at maximum we can copypaste or drag&drop and in Unix we can combine but every time we need to mangle text since there is no common language for anything, what we use is the shell, not "the system" witch is written in a separate compiled language. We can't circumvent this limit with all modern systems. That's is.
So despite the idea of simply storing contacts with a tool that allow easy export in various format might be effective in some cases we will anyway hit an integration wall sooner or later, let's say another app who need another kind of export and so on and the simple language became more complex while still remain unable to add anything else on top/related to contacts details do to "app separation" bound to the system design. It's a nice effort, and I thank the author for sharing the code, it might be helpful for some only we need a different software architecture to really manage our digital life, one we abandoned decades ago, the concept of an OS as a single application/framework where anything is runtime editable code, user-programmable, a single language, so we can just access functionalities via common data structure and functions instead of the integration hell we know very well.
> integration
The way this minilanguage works is that all contacts app can push/pull a `contacts.scroll` in a git repo. That's the database: a plain text file in a git repo.
The way this minilanguage works is that all contacts app can push/pull a `contacts.scroll` in a git repo. That's the database: a plain text file in a git repo.
Yes, but any other app need to explicitly integrate it, and it the biggest issue in modern software. Let's imaging such project is an Emacs package, you do not need any change from notmuch, mu4e, gnus, meow, ... to use your package, you can just put a bunch of advises, hooks, some functions wrapping some others etc, it's YOU the one who can integrate. In modern software it's the opposite and that's why anything fails because you can convince some apps to support this projects while some others will do not and to communicate you need some import/export solution/bridge and so on.
Modern software is a series of walled gardens with an enormous amount of resources to plumb something in between as a result only some projects who get enough popularity have chances of integrations, the other will remain standalone, and most tend to try implementing any possible features becoming monsters of bloats after a bit of time. There is no escape in such model, the modern web is not a valid answer, we simply need the classic OS as a single app/framework but this being incompatible with commercial software (at least it can only be mono-vendor) is a thing nobody in modern industry accept.
It's simply about time to admin that software can only be FLOSS and the competition can only be in hw. Meaning things we need to build as products, with raw materials not simply "selling some copies/bit", or "physical economy" vs "paper/finance one".
Modern software is a series of walled gardens with an enormous amount of resources to plumb something in between as a result only some projects who get enough popularity have chances of integrations, the other will remain standalone, and most tend to try implementing any possible features becoming monsters of bloats after a bit of time. There is no escape in such model, the modern web is not a valid answer, we simply need the classic OS as a single app/framework but this being incompatible with commercial software (at least it can only be mono-vendor) is a thing nobody in modern industry accept.
It's simply about time to admin that software can only be FLOSS and the competition can only be in hw. Meaning things we need to build as products, with raw materials not simply "selling some copies/bit", or "physical economy" vs "paper/finance one".
> it's YOU the one who can integrate. In modern software it's the opposite
Ah I see what you mean. Yes I agree.
> It's simply about time to admin that software can only be FLOSS and the competition can only be in hw. Meaning things we need to build as products, with raw materials not simply "selling some copies/bit", or "physical economy" vs "paper/finance one".
Agreed!
Ah I see what you mean. Yes I agree.
> It's simply about time to admin that software can only be FLOSS and the competition can only be in hw. Meaning things we need to build as products, with raw materials not simply "selling some copies/bit", or "physical economy" vs "paper/finance one".
Agreed!
Sorry, in general I comment quickly and my English is still poor enough to be not so clear in some cases, I'll try to do better when I see issues, but still sometimes I remain unclear :-)
Anyway really dream a modern system like Emacs where you can simply "plug some code" in someone else "app" on your system, how easy it could be extending and also evolving thanks to idea circulation because well, a small "package" is easy to read and understand and being not "another whole app" but just a kind of "plug-in" it's far easier to try.
Choosing the current pro-commercial model we have already lost decades of potential evolution only for a bad base design... You can extend that to anything else: a washing machine? Imaging if it's control panel is just and open interface with a common standard communication protocol: you can integrate it in your p.v. and make your wash in self-consumption issueless, it would be so simple most geek can do showing a potential evolutionary path to others. From this to a simple "smart home" where all appliances run one after another to maximize self consumption, than a different design for new machines (let's say instead of one big induction coil many little to being able to tune the load) and so on, with innovation happening at almost all levels like in classic FLOSS but IRL, not just in some geek projects.
Anyway really dream a modern system like Emacs where you can simply "plug some code" in someone else "app" on your system, how easy it could be extending and also evolving thanks to idea circulation because well, a small "package" is easy to read and understand and being not "another whole app" but just a kind of "plug-in" it's far easier to try.
Choosing the current pro-commercial model we have already lost decades of potential evolution only for a bad base design... You can extend that to anything else: a washing machine? Imaging if it's control panel is just and open interface with a common standard communication protocol: you can integrate it in your p.v. and make your wash in self-consumption issueless, it would be so simple most geek can do showing a potential evolutionary path to others. From this to a simple "smart home" where all appliances run one after another to maximize self consumption, than a different design for new machines (let's say instead of one big induction coil many little to being able to tune the load) and so on, with innovation happening at almost all levels like in classic FLOSS but IRL, not just in some geek projects.
And a nitpick: it cannot be both "open source and public domain" -- open source means it's licensed under an Open Source license, while public domain means that there are no IP rights.