Aaron Parecki

Actually if you also run high-res GPS logging then the visit data is basically 100% accurate. It records a visit exactly 10 minutes after you stop somewhere. If you want to experiment with it, that's what all the toggles in Overland are for! https://overland.p3k.io

It's *pretty* good, especially when combined with some regular GPS updates. Some additional processing and you can do pretty well. But like I said, I still need to do some more experimenting tho.

Great writeup! So glad to have helped someone else own their location history! and thanks for the 🍻!

I've been meaning to add more visit detection to Overland. It'll record good raw visit data right now but there's no venue detection yet.

Right now this library is for use when building a Micropub server. I haven't decided whether I want to also add Micropub client functionality to this library or release that as a separate library. I could probably be convinced both ways.

wait... didn't they make a whole web app for this? It's called "docs" or something I think.

This has been discussed a bit more on the IndieWeb wiki: https://indieweb.org/RelMeAuth#Consolidated_identities_do_not_carry_inherent_trust

This is a question for the RelMeAuth spec, which indieauth.com implements. I like the idea, it's just a matter of figuring out the best rel value now.

Stepping back a bit, I think we should look at the end goal from the users perspective.

This seems to be a problem primarily when both people have their own website and their content is automatically pulled into micro.blog from their own feeds.

With that in mind, the best solution is one which will require the least amount of behavior change as well as technical change on behalf of both people. This likely means micro.blog will have to do some additional work, but that seems appropriate since in this situation micro.blog is acting as an aggregator between two independent websites.

The way micro.blog can best facilitate this kind of interaction would be to match up the replies itself, and not require any additional steps for the user replying. Since micro.blog is already consuming a feed from my site, if it encounters any posts in that feed with an in-reply-to url, micro.blog should check whether that url is one of its own, or whether it's indexed as a canonical url from someone's site that it has also previously pulled in. Then it can match up the conversation thread. If there is no match, then a perfectly acceptable first version would be to just ignore the post and not pull it in to micro.blog at all. This way neither the person replying nor the person being replied to need to fiddle with any markup or make additional feeds or make decisions about syndicating at each post.

I believe JSONFeed has the concept of an in-reply-to url, but Atom/RSS do not. This means this feature will only work with JSONFeeds, but I think that is an acceptable compromise. Of course if micro.blog started consuming h-entrys that would also work but that's a different conversation.

Delayed. New estimated departure time is 10:15am.

I do think it should be a preference, tho maybe hidden by default is okay. The trick is once the channels without new content are hidden, you have to have a way to quickly show them again in case you want to be able to look at old content again.

As for the posts: Slack, IRC clients, as well as Twitter, show all the posts, not just the unread ones. I don't think I personally would use the "show only new posts" feature except in certain cases such as when I suspect there might be some old unread posts that have been buried somehow. I prefer to have some visual indicator about whether a post has been read rather than hiding it completely. In either case, you'd need a quick way to toggle between showing all posts vs showing unread posts.

My IRC client also does this and it's great

It was! Vodka OJ and Cranberry frozen then shaved into a glass!

@waxpancake did essentially this for himself, and made it public: http://belong.io

Thanks! It's an additional layer of security. Without it, you need to use additional techniques such as strict redirect URL validation and even PKCE to compensate.

Feel free to send me an email https://aaronparecki.com/contact

This is exciting. This will motivate me to work on the multiple destination support I have in mind for my website!

That makes sense, and also fits nicely with the idea of this as an extension rather than part of the base spec.