Tag: dopplr

Posted on
by

The WordPress ActivityPub plugin by Matthias Pfefferle has been updated. It now allows you to @mention ActivityPub users and they will be notified of the mention in your blogpost, through ActivityPub.

This is useful. Yet, I’m holding out on using the plugin myself until three things are possible:

  • Set the user name of the ActivityPub account: Now the username is the login name of the user doing the posting. I recognise using WP user names is a straightforward way of turning WP into an ActivityPub client, and prevents having to add addditional stuff to the database. As I use non-obvious user names for additional website security, having those exposed as ActivityPub users is undesirable however.
  • Refuse follow requests: currently the plugin allows follows, and defaults to accepting all follows. As on my separate AP account I want to decide personally on follow requests.
  • Determine flexibly which postings get shared through ActivityPub, and through which ActivityPub user account. The current set-up is that all postings get shared through ActivityPub. I’d rather be able to determine not just on a post by post basis what gets shared but also to have specific categories of postings to be shared through a specific account.

I want to actively use the affordances ActivityPub allows on top of those WordPress as blogging tool provides. For me that is the ability to use the different activity types that AP can support, and to use dealing with followers and follows to selectively disclose content to different groups of people.

My current usecase for this is to have a separate AP account that shares my travel plans (posted in an unlisted category on my site) with accepted followers. The first part requires selectively sharing a category of postings, the second part doing so to a group of accepted followers on an AP account that is meant for just this type of postings and not my general AP account.

The plugin will develop in this direction, but is not there yet. I am slowly going through the code of the plugin myself to understand its architecture and choices. Perhaps it will give me an idea either on how to build on its core to create the functionality locally I want for myself, or maybe (though my coding skills are likely not adequate for it) add to the plugin itself.

Posted on
by

I hadn’t really looked, but it turns out that Mastodon has incorporated microformats. It has h-feed and h-card, h-entry (a status), and h-cite (a boost). Plaint text properties (p-), e-content, and link properties (u-) are implemented. Indeed, they all surface when looking at a profile’s HTML source. This is what makes it possible to e.g. follow Mastodon feeds as h-feed, next to the existing RSS output and ActivityPub, and that e.g. Brid.gy can do its work to carry over any interaction on a Mastodon post to a blogpost here.

What I haven’t found was what I was looking for.
The ActivityPub protocol in its specs has several so-called Activity Types that drew my attention:

In short ActivityPub supports FourSquare and Dopplr like check-ins and travel plans. I’ve recently added that to my site in terms of microformats and was still wondering how to create a useful stream for it. I’ve been thinking about an OPML outline with schema.org attributes, or a dedicated RSS feed or h-feed. An ActivityPub stream might be of interest too, or even more. There’s a PHP implementation of ActivityPub that includes these Activity Types as well, meaning there’s potential to experiment for me.

I wonder, are there any actual implementations of these ActivityPub types currently?

Posted on
by

I assume that in its most basic form I could redo Dopplr of sorts by announcing travel plans in an OPML file, much like book lists or my rss subscriptions. Then it comes down to how to share such travel plans with a known and limited network only. (You don’t want to announce to just everyone when you won’t be home.)

The IndieWeb efforts concerning travel seem to focus on posting actual travel movements, like planned flights. A sort-of check-in style post. The socially shared Dopplr info was much simpler: a city and a set of dates. Because its purpose was aiding serendipitous meet-ups. Exact travel plans or exact location aren’t needed for it, just a way to flag paths more or less crossing to those involved.

Of course making such an OPML file currently is as easy as posting an empty file, as there’s no significant travel during the pandemic.

Theoretically I could use such an OPML file to announce several things:

  • The various cities I consider as home turf, as they’re within easy reach in an hour.
  • Selected cities I’m willing to travel to at short notice outside that hour travel time if there’s a good reason to.
    From where I am a visit to Antwerp, Brussels, Eindhoven would count in that category, or maybe on specific occasions Düsseldorf or Cologne.
  • Upcoming travel plans, things like ‘Copenhagen, Denmark, 4th-7th September’ (actually a 2019 example)

Such a list would allow comparison with your list to see whether any of your travel plans match with my ‘home turf’ and destinations I’m willing to consider outside of it, whether any of your travel plans match with my travel plans, or whether any of my travel plans line up with your home turf and other relatively nearby destinations you’re willing to consider. Cities and countries are part of schema.org vocabularies and as such usable in OPML as data attributes.

I think there’s a space for location based services, such as Dopplr was, that don’t depend on or use maps, but provide location contextualized information that influences my actions, choices and my relationships to my networks (a quote from a 2012 blogpost on moving beyond the map).

Or this is just me applying my current opml hammer to anything that might be a nail 😀


I couldn’t resist making this mock-up mimicking the colorful Dopplr

Posted on
by

Could one redo any useful app, for that matter, that now fills the start-up cemetery?

I was reminded of this as Peter mentioned Dopplr, a useful and beautifully designed service in the years 2007-2010. The Dopplr service died because it was acquired by Nokia and left to rot. Its demise had nothing to do with the use value of the service, but everything with it being a VC funded start-up that exited to a big corporation in an identity crisis which proved unequipped to do something useful with it.

Some years ago I kept track of hundreds of examples of open data re-use in applications, websites and services. These included many that at some point stopped to exist. I had them categorised by the various phases of when they stalled. This because it was not just of interest which examples were brought to market, but also to keep track of the ideas that materialised in the many hackathons, yet never turned into an app or service, Things that stalled during any stage between idea and market. An idea that came up in France but found no traction, might however prove to be the right idea for someone in Lithuania a year later. An app that failed to get to market because it had a one-sided tech oriented team, might have succeeded with another team, meaning the original idea and application still had intrinsic use value.

Similarly Dopplr did not cease to exist because its intrinsic value as a service was lost, but because everything around it was hollowed out. Hollowed out on purpose, as a consequence of its funding model.

I bet many of such now-lost valuable services could lead a healthy live if not tied to the ‘exit-or-bust’ cycle. If they can be big enough in the words of Lee Lefever, if they can be a Zebra, not aiming to become a unicorn.

So, what are the actual impediments to bring a service like Dopplr back. IP? If you would try to replicate it, perhaps yes, or if you use technology that was originally created for the service you’re emulating. But not the ideas, which aren’t protected. In the case of Dopplr it seems there may have been an attempt at resurrection in 2018 (but it looked like a copy, not a redo of the underlying idea).

Of course you would have to rethink such a service-redo for a changed world, with new realities concerning platforms and commonly used hardware. But are there actual barriers preventing you to repeat something or create variations?

Or is it that we silently assume that if a single thing has failed at some point, there’s no point in trying something similar in new circumstances? Or that there can ever only be one of something?



Repetitions and Variations, a beautiful Matisse exhibit we saw in 2012 in the Danish national art gallery in Copenhagen. Image by Ton Zijlstra, license CC BY-NC-SA


12 stages, 1 painting. I’m thinking the reverse, 1 sketch, 12 paintings. Image by Ton Zijlstra, license CC BY-NC-SA


Normandy Cliff with fish, times 3. Matisse ‘Repetitions and Variations’ exhibit. Image by Ton Zijlstra, license CC BY-NC-SA

Posted on
by

Kilroy black edited

Social geolocation services over the years have been very useful for me. The value is in triggering serendipitous meetings: being in a city outside my normal patterns at the same time someone in (or peripheral to) my network is in the city too, outside their normal patterns. It happened infrequently, about once a year, but frequently enough to be useful and keep checking in. I was a heavy user of Plazes and Dopplr, both long since disappeared. As with other social platforms I and my data quickly became the marketable product, instead of the customer. So ultimately I stopped using Foursquare/Swarm much, only occasionally for international travel, and completely in 2016. Yet I still long for that serendipitous effect, so I am looking to make my location and/or travel plans available, for selected readers, through this site.

There are basically three ways in which I could do that.
1) The POSSE way. I post my location or travel plan on this blog, and it gets shared to platforms like Foursquare, and through RSS. I would need to be able to show these postings only to my followers/ readers, and have a password protected RSS feed and subscription workflow.
2) The PESOS way. I use an existing platform to create my check-ins, like Foursquare, and share that back to my blog. Where it is only accessible for followers/readers, and has a password protected rss feed.
3) The ‘just my’ way. I use only my blog to create check-ins and share them selectively with followers and readers, and have a password protected rss feed for it.

Option 3 is the one that provides the most control over my data, but likely limits the way in which I can allow others to follow me, and needs a flexible on-the-go way to add check-ins through mobile.
Option 2 is the one that comes with easy mobile apps, allows followers to use their own platform apps to do so, as well as through my site.
Option 1 is the one that is in between those two. It has the problems of option 3, but still allows others to use their own platforms like in option 2.

I decided to try and do both Option 2, and Option 3. If I can find a way to make Option 3 work well, getting to Option 1 is an extension of it.
Option 2 at first glance was the easiest to create. This because Aaron Parecki already created ‘Own Your Swarm‘ (OYS) which is a bridge between my existing Foursquare/Swarm account and Micropub, an open protocol for which my site has an endpoint. It means I can let OYS talk both to my Swarm account and my site, so that it posts something to this blog every time I check-in in Swarm on my mobile. OYS not just posts the check-ins but also keeps an eye on my Swarm check-ins, so that when there are comments or likes, they too get reflected to my blog.

My blog uses the Posts Kinds plugin, that has a posting type for check-ins, so they get their own presentation in the blog. OYS allows me to automatically tag what it posts, which gets matched to the existing categories and tags in my blog.

I from now on use a separate category for location related postings, called plazes. Plazes was the original geolocation app I started using in 2004, when co-founder Felix Petersen showed it to me on the very first BlogWalk I co-organised in the Netherlands. Plazes also was the first app to quickly show me the value of creating serendipitous meetings. So as an expression of geo-serendipic (serendipity-epic?) nostalgia, I named the postings category after it.

Posted on
by

In the period 2007-2009 I was a heavy user of Dopplr, a geographic context tool. You’d add your upcoming trips to it, “I will be in Zurich January 4th”, and share it with your network “Your contact E.R. will also be in Zurich that day, and your contacts A.G., H.G. and A.A. live there.” This was helpful to spot potential face to face meet-ups with those people in your network you’d normally not bump into. It was a geographic serendipity tool, and it helped me meet up with people in my network regularly enough to make it worthwile to add my trips to Dopplr. For instance it enabled having a beer with Thomas (his and my photo of that moment). In 2007 I wrote about how Dopplr played a role in my digital routines, and in 2009 how I liked it as a contextual tool that, although geography based, doesn’t use maps.


typical messages from the original Dopplr, image Sebastian Küpers, license CC BY.
typical messages from the original Dopplr, image Stowe Boyd, license CC BY NC.

In 2009 Dopplr was acquired by Nokia, and similar to other useful tools Nokia bought (such as Plazes), it was then phased out. At some point (June 2013) I deleted my account, which by then had been dormant for a long time, after downloading all my data.


Every year you received a beautiful overview of all your travel movements. Image Ewan McIntosh, license CC BY NC..

Now the domain Dopplr2.com is active (the original dopplr.com domain now hosts a site looking at legal aspects of current news) and promises to relaunch a similar service. It uses the same colors as the logo of the original Dopplr, so I will be curious to see what they offer when they launch.