I installed delta.chat on my phone, to play with, nudged by Frank’s posting. It’s a E2E encrypted chat application with a twist: it uses e-mail as infrastructure. You set it up like an e-mail client, giving it access to one of your e-mail accounts. It will then use your e-mail account to send PGP encrypted messages.

So it’s actually a tool that brings you encrypted mail without the usual hassle of PGP set-up. Because it uses mail, you can find your messages in your regular mail archive (but encrypted), and you can contact anyone from the app if you have an e-mail address. The first message you send will be unencrypted (because you nor the app knows if the receiver has delta.chat installed), afterwards it will be encrypted as the app will have exchanged public encryption keys. Using e-mail means it’s robust, it doesn’t suffer from ‘there’s noone on here’ and there’s no silo lock-in. It also doesn’t need your phone number. It does ask for access to your contacts, which I denied as it is not at all a given that people will run delta.chat with the e-mail addresses they normally use.

I’ve tied it to my gmail address for now (ton dot zijlstra at gmail, ping me on delta.chat if you use it), because I wanted to have an easy interface to check what is going on in my inbox, and I have gmail on my phone anyway (even if I don’t use it for anything). I may switch over to a dedicated e-mail address later.

Some screenshots to illustrate:

Screenshot_20210218-090559_Delta Chat
How my initial exchange with Frank looked in Delta.chat


How my message to Frank looked in my mail. As it’s the first message it was unencrypted.


How I received Frank’s reply, which has an encrypted attachment.


The encrypted attachment when opened in a text editor shows it’s PGP.

I haven’t explored whether I can export my keys from Delta.chat. If you can’t, without Delta.chat I have no way of opening them. It’s a local tool only, so I suspect I might be able to get access to the keys outside of the app.

Peter in his bookmarks points to a description of Bookfeed.io by Swiss blogger Lukas Mathis. Bookfeed.io lets you make a list of authors you are interested in, and then provides you with a RSS feed that will alert you to new books published by those authors. It uses the Google Books API. It’s a clever small personal tool that Lukas Mathis built. I like it. I’ve added a handful of authors from the top of my head, and subscribed to the resulting RSS feed. I also added a monthly reminder to my task list to add or remove authors from the list.

De Open State Foundation en SETUP lanceren de SOS Tech Awards gericht op transparantie en verantwoordelijkheid in de digitale samenleving.

De Glass & Black Box Awards gaan over openheid en transparantie. De Dode & Levende Mussen Award gaan over verantwoordelijkheid nemen na technologische missers, en de mate waarin bedrijven en overheden niet alleen excuus aanbieden maar ook echt hun handelen aanpassen. De genomineerden worden in de komende weken bekend gemaakt. De SOS Tech Awards worden op dinsdag 23 maart 2021 uitgereikt via een livestream vanuit de centrale Bibliotheek Utrecht.

(In het kader van transparantie: ik ben bestuurslid bij de Open State Foundation)

Lukas Rosenstock posted a write-up of a group discussing their personal CRM routines he organised. A little over a year ago I was impressed with how Rick Klau (an old blogging connection) described his ‘homebrew CRM‘.

Lukas mentioned there were three groups in his conversation, one using specialised tools, one group using no digital tools, and one group using more general tools (“like Roam, Notion or Airtable“). I’m definitely one of the latter.

After reading Rick’s posting a year ago I parked it for a while, but when I adopted Obsidian for note taking, after a while I also started using it for some light weight CRM notes. Unlike Rick I haven’t added any process or automation, but I did start creating CRM notes so that something like it might become possible over time.

What I started with is making notes about people I encounter.

LinkedIn has one glaring hole in its functionality and that is allowing me to add something about the context of when I met someone. After using LinkedIn for 16 years I now sometimes come across a LinkedIn contact and then don’t remember how or why we connected. LinkedIn by now does show when you connected, allowing me to browse through someone’s CV to see what that person did when we connected and try to remember the context of that connection. Xing, mostly used in German speaking countries, had this from the start including a field for a few notes on when / how you met someone. That has proved valuable. [UPDATE In the comments Aad points out such a feature has been present at some point. Online search suggests it was introduced in 2013/4 with LinkedIn Contacts, and became a premium-only feature from 2017. By 2013 I had some 2k contacts, 8 years worth of interaction, where such contextual info was missing, and I use the free version, so the general point stands, even if factually not correct since 2013]

Back when I used a wiki on my laptop for notes, I also kept CRM style notes in it, especially 2004-2008. The useful bit was that I could link to a person’s page in the various notes I made about meetings, events etc. That ‘backlinking’ overview in itself was a great way of adding contextual info.

With Obsidian and the use of simple text files in markdown I have that back, and actually in a better way than in that wiki of old. Because those text files can be approached by a wide variety of software tools, not just Obsidian.
I’m not attempting to be complete in these CRM notes, I grow them the same way as I grow the other type of notes: when I encounter someone new I make note of it. Especially when I don’t know someone yet, or don’t have a strong connection to someone I make those notes. Not so much of people that I’m already connected to like colleagues. I’ve started a few new projects in the past few months, which is always a moment when you encounter a lot of new people in a new context. So those I’ve made notes for, as it helps understand a new client organisation, relevant stakeholders and context. For now backlinking in meeting and project notes is the way for adding a record of interaction.

Maybe in a year or so I can start doing more pro-active things with those notes, like Rick has built into his routines. Another element to me is potentially leaving LinkedIn behind at some point in the future, or at least be somewhat prepared when LinkedIn goes away, as all these platforms do.

Do you have some personal CRM-type routines or automation?

HandShakeHandshakes and conversations is what I’m interested in, not marketing instruments. Image Handshake by Elisha Project, license CC BY SA

Two years ago I wrote about the features I’d like to see in an ideal feed reader. Today I’ve tried to sketch out the various components, based on the various IndieWeb protocols, and then match the features I listed previously to the component that I think should provide it.

Separating feed reading into IndieWeb components

Feeds from blogs, to the left in the sketch below, end up in a microsub server, whose function is to fetch and store feeds. A microsub client is what presents those fetched feeds to me. A regular feed reader usually does both these things, but splitting them like the IndieWeb does allows multiple clients to use the same collection of feeds and feed items. It allows a wider diversity of readers, if the fetching is dealt with separately.
The microsub client also contains a micropub client. This allows having action buttons underneath each item presented in your microsub client. Hitting a button posts your reply or remarks, or shares something to your own website, and through your site to e.g. Twitter or Mastodon. Ideally it would be possible to have different websites to share to, next to storing locally in a specified format. The website that receives such an action has a micropub endpoint, and may need authentication through IndieAuth.

Such a reader set-up should be able to run locally on my laptop, as well as on a basic hosting package, so likely php / mysql based. Locally because I want to run my stuff local first, but the same thing online, even if a home server, because I’m not always working on my laptop and would like access from my tablet too, and point my Android Indigenous app to my subscriptions. Locally I would not need authentication from the microsub client to the microsub server, but in all other situations I would.

The sketch above is completely congruent with how I sketched my information gathering and filtering process in 2005:

filter1.jpg

Matching the ideal functionality to IndieWeb components

When I match the features of my ideal feed reader to those various IndieWeb components I think this is what results:

Microsub server needs to be able to :
* use various kinds of feeds (rss, atom, json, h-feed)
* allow folders (so I can arrange feeds on social distance)
* recognize and store tags if feed items have them
* allow me to tag _feeds_, really meaning tagging authors
* keep track of posting frequency, last post seen of feeds
* keep track of tags or predefined topics mentions/frequency
* pull in machine translations by default for certain feeds and store them with the orginal item

Microsub client needs to be able to:
* present the feed items in the server’s folder structure as a long list (the classic feed reader view)
* present views based on patterns in current feed items: what’s hot, what’s unique? Also set against social distance. (Topics discussed in my communities today)
* present views based on feed tags (show me all Germany based blog items of this morning, show me every feed of from EU based coders)
* present views based on feed tags and item tags: show me Germany based blog items talking about topic X.
* show full text search results of all items mentioning a certain topic.
* store full text search queries
* present visually which topics seem to be hot in which community, or where the frequency of mentioning a topic has changed
* provide a search of feeds (not feeds content): do I already have this feed in my list, where’s the feed of author Y?
* pull in a machine translation on request

Micropub client needs to be embedded in the microsub client and should support:
* saving an article as markdown or as html, to disk, to Zotero
* creating a todo from it by amending a textfile,
* bookmarking it, either to my blog or some other target
* sharing something about it to my blog, to Mastodon through my blog
* replying to it, through my blog to Mastodon, Twitter, other blogs
* allow configuring new actions.
* choosing from multiple micropub endpoints

What do you think, should some of these features be provided by other components than they’re currently listed? Are features missing that you’d like to see in your ideal feed reader?