[catgirlinspace]new idea. i just, do relmeauth on my own site for auth. except itd just be github oauth. no passwords to store then and i dont have to learn how to use webauthn which makes like, 0 sense...
[snarfed]any thoughts? BF currently supports 410, and it has a request for u-unfollow-of also, but I'm inclined to say no, that plus a UI for it is enough
aaronpkpublic content should be public content and you can read it without the publisher knowing who you are. If you want to publish content for a specific audience, you can give them a way to authenticate, at which point you should know that they are fetching your content
[snarfed]agreed, following in a reader is internal to the reader, no need to publish anything. I guess then I wonder how much blogrolls and follow posts should/could overlap? could a blogroll just be an h-feed of h-follow-ofs?
[snarfed]this also implies that tools like Bridgy Fed shouldn't actually expect to handle follow/unfollow via webmention + mf2. following in readers or BF would generally only be in their UIs
[snarfed]interestingly social networks kind of take the opposite tack. following someone both follows them (ie adds them to your timeline) _and_ shows them in your following list (equivalent to blogroll/list of follow posts), which is public if your account is public
capjamesgI am unsure whether mf2/webmention following is in scope for BF right now given the lack of people publishing / interested in processing follows outside of AP.
IWSlackGateway, [snarfed], [snarfed]1, [aaronpk], [aaronpk]1 and [aaronpk]2 joined the channel
[0x3b0b]I think there are a few aspects of BF where the decisions are likely to be different depending on whether you are trying to provide Least Surprise for the side being bridged to or the side being bridged from...
[tantek]aaronpk @vocab is how LD does mapping between different property names (URLs) that have the same semantics I believe so that a "full LD processor" can treat them as the same thing in memory or something
aaronpk> @vocab is used specifically to declare a default vocabulary from which all terms derive, without having to declare specific mappings for each term (as you normally do in a @context).
[snarfed]extracting and using date from EXIF sounds doable entirely inside your own web server, doesn't really need any standards anywhere other than EXIF, right?
[catgirlinspace]i wannya do something where i can upload pictures to my website and it stores the original + a version where gps is removed, then display the safe version publicly along with a little display for the other exif data for like, camera used and stuff.
GWGaaronpk: If I upload a photo it stores that information in my site already... but it doesn't set the publish or location property of a post based on it
[schmarty]You're getting close to my ideal checkin client! Use time and location data from one or more photos, reverse-geocode for address, optional comment and tags, tadaaaa
[tantek]only for new venues presumably. if you've checked in there before, you can likely re-identify when you're at the same venue and skip all the reverse geocode hoohaw
aaronpkfor a while i was doing auto-checkins, if I was in a location for more than 10 minutes it'd check if there was an unambiguous place I had been to previously and check me in automatically
[tantek]heck, if you're following friends checkins, cache all their venues as well, and use those as an L2 location cache even for first time checkins at venues
[tantek]beyond that you could add an L3 location cache by preloading venues adjacent to venues you've been to before, or for any street segment with 2+ venues you've checked into, preload that entire segment of venues into L3
[tantek]having your prior venues (L1), your friends prior venues (L2), and pre-loaded adjacent / same-street venues (L3) in a cache means you can load that cache clientside and eliminate network latency for my guess is 99.9% of checkins, especially in urban areas.