Thoughts: The requirement of apps to have a publicly accessible website conforming to the IndieAuth API might be a limiting factor
On the other hand, globally unique identifiable apps is a huge benefit in terms of admins being able to restrict app access. I.e., currently every user can revoke app access to their account, but server admins cannot say "I don't want the cross-poster to work with my server" because there is no such thing as *the* cross-poster
IndieAuth sounds interesting as a more generic way for federated applications to allow app registrations https://indieauth.spec.indieweb.org/
The question is how do we adapt this after our current, extremely similar but somewhat different system has been in production use for around 2 years #mastodev
@gargron isn't it great though
i mean the whole thing of registering apps has mostly been justified by commercial restrictions and a pain in the ass for developers and users
Another nice post on the Mastodon blog about implementing ActivityPub: https://blog.joinmastodon.org/2018/07/how-to-make-friends-and-verify-requests/
It would also be nice to add IndieAuth to the Indiepaper website, which could then generate bookmarklets and macOS configuration links automatically based upon the IndieAuth exchange.
For the use case of Aperture, the user would log into www.indiepaper.io with https://aperture.p3k.io, and then would select a channel to publish to during the auth flow.
Phew! After long awaited anticipation, I’ve built in a draft version of automated webmentions into my site, so now when I like and reply things from my Social Reader my site will send out a webmention immediately. No more 1-2 delays in my replies 😁🎉
At the end of the day federated social software is only kinda good at content consumption and does almost nothing for content production and people like using computers more to make things than they do consuming of things
feel like we should really have a focus on making things and again and making that as seamless and easy as possible
