<@!933382249146101820> I'm thinking along very sim...
# chat
c
@User I'm thinking along very similar lines. My plan is to do something closer to what @User suggested though. I imagine having data in dendron where one of my vaults is synced to other services. For example, xandikos is a CardDAV/CalDAV server that stores its data in git. I'm scheming about how to either make it a dendron "pod", or write my own tooling to keep it in sync with a dendron vault. Would it be crazy to consider pooling our efforts?
s
@User Cool! I'm open to pool efforts. Heres a schema I created for a contact manager. Holds both
organization
and
individual
contacts. Was going to work at turning it into Dendron templates next.
Or if you prefer a JSON view of the ERD...
json
c
My thinking was to use fairly reduced / simple YAML inside my note, something like this:
Copy code
name: Jane Doe
phone:
  type: mobile
  value: +12345
email:
  type: work
  value: jd@
I figured I'd add that to the frontmatter, along with some kind of unique ID which is compatible with the VCF spec, and then sync the two.
@User It seems like you're more going for embedding valid VCF data inside markdown notes. Did I get that right?
s
I don't know! HAHA. I'm just hacking on some ideas. I'm unfamiliar with what can be done with YAML frontmatter. I envisioned the workflow of...
- I need to add a new
person
to my notes - stored under the
person.md
node - Dendron Lookup Note.
person.md
- Summon a User Snippet to act as a "form" of sorts - Fill in the blanks - Save - At some point, my (Python) parser would scrape the most recent People in
person.md
and upload it into a SQL DB
c
What do you do with the SQL DB?
s
Good question. It becomes my contact manager for use outside Dendron. Because all the people are captured inside Dendron too, I can related them to Notes, Event, etc.
Again, just a idea
c
The linking, etc is exactly why I'm interested in this.
But I think getting the contacts into my phone, email client, etc, is my goal.
s
Makes sense
c
That's where the xandikos idea comes in. It stores its data in plain text files in git. So syncing between git + dendron and git + xandikos seems like a fairly manageable task...
s
Ok! How does YAML play a part?
I thought the contact details would be in MD
c
Well, yaml "frontmatter" is the "data" part of a markdown file.
s
hm...
How would you link to the details of a person in your other notes?
c
Just the same as a regular link in dendron.
One file per person.
people.jane-doe.md
- contains both the data for that person, and potentially notes, history, or any other writing I fancy.
s
Ah yes. I was going to go there as well.
The problem I had is the "data" part
There is a LOT of contact data to store if you want to get intel
c
My sense is that the VCF spec supports a mountain of different types of data. But in reality, I care about probably less than 6. I have first & last names, company names, phone numbers, email addresses, postal addresses, and notes. I don't think in my ~3k contacts I have any other fields. Maybe URLs.
s
There is a fine line between an "Contact Manager" and something that just grabs phone numbers
c
So I imagined keeping it fairly simple in terms of format on the markdown side, and making some assumptions on the VCF spec side.
The folder of markdown data would be my "source of truth", but in an ideal world, I'd be able to make changes to that directly on my phone.
However, that is honestly a "nice to have". If I could just take my markdown and programmatically generate valid VCF data which xandikos could serve, that would already be good enough that I'd dump monica (php crm) and use this instead.
s
Gotcha! Sounds good!
c
I'm more familiar with typescript than python though, sounds like maybe you're more comfortable in python?
s
exactly
c
I've written some python in my life, but the thing that I struggled with was shipping it. Whereas with npm I understand that ecosystem and so I could imagine other people being able to download the script and run it.
s
I think thats awesome. We can bounce ideas and keep the conversation going, share findings, test together, or whatever works.
Low key 🙂
c
Sounds good. I can imagine there will be a lot of messing around with the VCF format. Well, maybe there's a library for that already which solves it all, that would be nice...
searches yarn...
s
exactly! I'm sure theres a library
Right on man. Nice meeting you! Happy Hacking!
c
This looks like it could do the job. https://yarnpkg.com/package/@covve/easy-vcard
Doesn't read the format, just generates it, but it would work for the initial proof of concept, and it's remarkably simple to use.
Alright, will likely be ~3 weeks before I have time to do any serious hacking on this, but I'll ping you if anything changes sooner, and otherwise let you know once I have some progress.
Maybe before then we could figure out what to name fields, etc and how to format it in the yaml.
I'll try to whip something up and send you the link to review if you like.
s
Right on, for sure. Feel free to use the schema at the top for ref on what to name fields.
c
Your schema has quite a lot of links between different entity types. Do you have a sense of what to use those types for?
I wonder if you're imagining a specific use case, or more generally trying to model how you think the data is structured.
Are you deduping emails, phones, addresses, etc? So several contacts could have the same address and changing it for one would change it for the others?
Here's my first draft...
Copy code
yaml
company: JD Inc
full_name: Jane Doe
name:
  prefix: Dr
  suffix: MsC
  first: Jane
  additional: Middleton
  family: Doe
phones:
  - type: mobile
    phone: +1 234 567 1234
emails:
  - type: work
    email: jd@jd.com
addresses:
  - type: home
    line1: 8 51st St
    line2: apt 405
    city: New York
    postcode: 10111
    state: NY
    country: DE
urls:
  - type: github
    url: https://github.com/jd
  - type: twitter
    url: https://twitter.com/jd
But, maybe I prefer to put the
full_name
and
company
fields inside the
name
object. A contact record must have 1 name I'm thinking, and so it would make validation a little easier to check for at least one of first, last, full, or company name.
But that's a pretty big deviation from the vcard spec.
Also, the vcard spec uses
tel
and not
phone
, so maybe that would make more sense. I'm thinking that each of the
phones
,
emails
could be a single string instead of a type / value tuple. That way the syntax could be shorter in yaml.
s
RE: Links between entity types: - This is the normalized data structure I settled on when designing a contact mgmt tool - The "bridge tables" allow for many-to-one relationships of Phone, Socials and Locations for each Contact (whether Organization or Individual Contact) - Example: What happens when a Contact has more than one address? - I believe youd need two files for the same Contact in your YAML schema, correct?
Or maybe just a different address
type
, nevermind, I see now
If youre feeling adventurous! Here are some notes on how I landed on this schema! https://dba.stackexchange.com/questions/290092/what-is-the-correct-way-to-organize-tables-for-a-sql-view
c
Yaml supports arrays, the format is a bit confusing, but essentially
phones
,
addresses
and
urls
are arrays of objects (in JavaScript terms). So multiple addresses would be supported. But a single address couldn't be shared between multiple contacts, which would be possible in your schema.
Have you found any existing projects which do anything similar? I'm wondering if we're reinventing the wheel, but so far I can't find anything similar...
s
@User did mention something along the lines... let me find the thread
Ahaha... nevermind. Its right above where we started chatting! https://discordapp.com/channels/717965437182410783/717965437182410786/935262231837429790
c
Have you spent any time on google / etc trying to find something similar?
s
Negative
c
Is that something you'd be interested in putting some time into?
s
I could do some research tomorrow eve. Criteria: - Are there any contact management projects that use YAML, JavaScript and VCF? - if so, summarize the project, grab resources, report-out Anything else?
c
Yeah, any existing prior art in this space that would be worth checking out. Anything to do with contacts / address books / etc in markdown and maybe yaml. The javascript part is not so relevant.
On one issue, the author of xandikos suggested that it would make more sense to use a CardDAV client instead of writing files into git directly. They make an excellent point. Being able to synchronise data between CardDAV and dendron would be super powerful, as it would support Gmail, Apple iCloud, etc, etc.
Bit more versatile than just pushing data into xandikos directly...
s
Ok. I'll jump into some research tomorrow
Alright buddy. I just submitted some initial research via an Issue on the GitHub site (I came across while researching!) https://github.com/GenerousLabs/md2carddav/issues/1
I'm still a little foggy on the infrastructure and how this project would work. I did learn a fair amount today which was nice. Hope this is useful!