3 ms·

Show HN: Contacts: A Microlang for Managing Contacts

15 points by breck 2y ago

gnud 2y ago
[flagged]
- breck 2y ago
  This documentary might change your mind: https://www.youtube.com/watch?v=JYqfVE-fykk https://www.youtube.com/watch?v=JYqfVE-fykk > There is _one_ correct way to write dates But seriously what if a comet hits earth at the perfect vector to reduce it's spin rate so that's it's slower than it's orbit rate?
deleted 2y ago
[deleted]
kkfx 2y ago
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 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.
- breck 2y ago
  > 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.
  - kkfx 2y ago
    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".
    - breck 2y ago
      > 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!
      - 2y ago
librasteve 2y ago
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 https://raku.land/zef:librasteve/Contact and would be happy to help. https://docs.raku.org/language/grammars https://docs.raku.org/language/grammars
- breck 2y ago
  Let's try it. Can you shoot me an email?
  - librasteve 2y ago
    librasteve at furnival.net
zvr 2y ago
Obvious question: how does it relate to vCard, which is the standard way of describing contacts? The examples shown are too simplistic for real world use: how do I specify multiple phones/emails, like work and personal? 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.
- breck 2y ago
  Looking at vCard (https://pldb.io/concepts/vcard.html 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.

15 points by breck 2y ago

gnud 2y ago

[flagged]

breck 2y ago
This documentary might change your mind: https://www.youtube.com/watch?v=JYqfVE-fykk https://www.youtube.com/watch?v=JYqfVE-fykk > There is _one_ correct way to write dates But seriously what if a comet hits earth at the perfect vector to reduce it's spin rate so that's it's slower than it's orbit rate?

deleted 2y ago

[deleted]

kkfx 2y ago

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 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.

breck 2y ago
> 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.
- kkfx 2y ago
  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".
  - breck 2y ago
    > 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!
    - 2y ago

librasteve 2y ago

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 https://raku.land/zef:librasteve/Contact and would be happy to help. https://docs.raku.org/language/grammars https://docs.raku.org/language/grammars

breck 2y ago
Let's try it. Can you shoot me an email?
- librasteve 2y ago
  librasteve at furnival.net

zvr 2y ago

Obvious question: how does it relate to vCard, which is the standard way of describing contacts? The examples shown are too simplistic for real world use: how do I specify multiple phones/emails, like work and personal? 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.

breck 2y ago
Looking at vCard (https://pldb.io/concepts/vcard.html 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.