Like, let's turn that question around a bit. What sorts of things are you thinking of and how does ActivityPub enable it in a way that works portably across multiple ActivityPub implementations?
@trwnh @jalcine I've written extensively about some proposals for how to handle authentication on Atom feeds. http://beesbuzz.biz/blog/4594-The-authenticated-Atom-musings-continue for example.
It's not a perfect solution but it's better than nothing, and it's not like ActivityPub actually solves the problem either.
@fluffy @jalcine the stuff i'm thinking of that could easily be done with activitypub that couldn't be easily done with atom:
- an email replacement
- accept/reject/add/remove semantics (not just CRUD)
- solving the "ghost replies" issue
- being able to use actor/activity model to get not only both client and server, but also data representation for free
- actually implementing logic without having to read 20 different specs
@trwnh @jalcine those are all fair points, for building systems that are different than the kinds of systems I want to build. I'm mostly interested in how to make blogging and web-based publishing/syndication better.
I'm of the mind that things should be designed with the UNIX philosophy: small, single-purpose things that interoperate in useful ways to build up larger things. And I don't have a problem with reading/implementing 20 specs if the specs are all simple.
Like, email has its problems but it's also not really going anywhere, so why try to replace it with something that can also do blogging and video sharing and social network pings and whatever? I want a really good tool kit, not a Swiss army knife.
@fluffy @jalcine yeah, that's the point i'm trying to communicate: the activitypub vs atom discussion is really only relevant for web-based publishing and syndication (although even then, i'd say that atom tends to be less efficient due to the way it handles feeds and introduces a lot of duplicate data)
when it comes to UNIX philosophy, i don't disagree, but i think what counts as a "single purpose" can be a bit wider.
@trwnh @jalcine I don't see the Atom stuff as being "duplicate data" so much as being different renditions that are appropriate to the user experience at hand. And at least in the case of superfeedr, WebSub ends up limiting the actual content pushes to only including new entries anyway (not that it's required by WebSub but it's nice that they do that).
I also think things like archive feeds (RFC5005) can address the issue in a nice way too, although support for that is slim. :(
@fluffy @jalcine i'd actually really like to replace SMTP even if it's "not going anywhere" -- i would much rather have email over activitypub or even xmpp than over smtp. smtp is a bad protocol that deserves to die, if it weren't for the problem of network effects and legacy adoption.
as long as the overhead remains minimal and you actually get a lot more, that is -- consider XMPP's presence awareness and overall much lighter message-passing semantics! consider the mess of smtp headers...
None of the current AP things seem to really be trying to do that though, every prominent AP project is basically trying to clone Twitter or Facebook, or provide a one-to-many publishing model that is very well-suited to Atom (e.g. replacing YouTube or Flickr).
@trwnh @jalcine I do admit that when I rant about AP I'm more ranting about Mastodon and Pleroma and so on but those are where all the development is happening and the whole promise of AP is "everything works through Mastodon" - but the more general use cases for AP that you're describing probably wouldn't, at least not very well.
the next-gen AP stuff will not be 100% compat with mastodon or pleroma, i can almost guarantee that. but compatibility doesn't have to be 100% -- only where it makes sense.
@trwnh @jalcine I think there's a bit of a chicken-and-egg problem where people want AP to have a Killer App but right now Mastodon *is* that Killer App, and that might make it discouraging to try to make something else that talks the same protocol but does wildly different things.
Of course Mastodon started out as a GNU Social/OStatus thing to begin with, and a lot of that legacy shows pretty severely as well.
@trwnh @jalcine well I take that back, the UX wasn't *horrible*, it's jsut that FoF is more for subscribing to things inbox-style and OStatus is more for blasting out short things rapidly, Twitter-style. They are both perfectly reasonable, but orthogonal, uses of the same protocol.
Which is of course the same thing that can be said for Mastodon and whatever other mythical APub things show up.
which is something that i think could be observed a bit more widely, too -- there's no reason to do activitypub *only* if atom can be added on top for at least feed-reader cases. it's just that i think if we stuck to atom only, we'd have missed out on technological progress.
@trwnh @jalcine But I'm also not fond of AP's addressing mechanism; I love how with Atom I can easily make a mapping between site content and Atom views of it. For example, http://beesbuzz.biz/blog/?tag=cpap maps (on my site) to http://beesbuzz.biz/blog/feed?tag=cpap - and it's easy to build an arbitrarily-complex but simple mapping like that. @view@domain doesn't seem to lend itself to any similar affordances. But that's another impedance mismatch.
like is there a difference between typing email@example.com or mastodon.social/@trwnh into a search box? i actively share the latter instead of the former. i think webfinger should die.
@trwnh @jalcine yeah one of my plans for Authl (the auth layer for Publ which I of course intend to be usable for other things) was to support Mastodon et al for identities, and the actual mechanics of doing that seem rather more complicated than they need to be. I think for the first pass I'm only going to bother with email, OpenID 1, and a handful of silo OAuth providers. Maybe IndieAuth if it feels justified.
@trwnh @jalcine Well I mean not a lot of people provide IndieAuth and there's still a huge barrier to adoption which mostly comes down to "host an endpoint yourself." It's great for IndieWeb folks but it's not my highest priority since I mostly want things that my non-indieweb friends can use.
OpenID 1 is dead but it's easy to support and there's still a lot of legacy providers for it, notably ones that a lot of my friends use it, thus my interest.
OIDC doesn't solve the problems OID1 did :(
@trwnh @jalcine like, Google, Dreamwidth, Ubuntu Launchpad, and a few other things still provide OID 1.x, and you don't need any peering agreement to use it. My understanding of OIDC is that you need to individually peer with the providers, making it not really any better than OAuth.
But all this shit is annoying and emailed "magic links" are probably what I'll implement first, because that's at least more or less universal.
@fluffy ehhh magic link is certainly better than password but one thing that bugs me when logging into loomio is i always wish i could just use a TOTP in enpass. getting into my email is slower than just checking my totp on the same device i'm already on
@trwnh yeah OID1 was so good, and it never really had a chance :(
@fluffy i feel like indieauth is at least trying to fill the same niche, with "enter a url and it'll do the authentication dance over there"
@trwnh yeah I do want to support it, and what I"m tempted to do is to build some sort of profile provider that lets people sign up for it with a username and password and all it does is provide a profile page with IndieAuth support. That would be incredibly useful for IndieWeb stuff in general and immediately give folks access to Microsub/Micropub/etc. via the myriad things at p3k.io
Heck, I'm sure something already exists, but it's been hard to actually find anything that's usable.
@fluffy @trwnh so IndieAuth doesn't explicit provide this but I'm going to have https://fortress.black.af emit the kind of profile info you'd see if you did a GitHub OAuth2 dance (by way of fetching someone's https://indieweb.org/representative_h-card or merging silo info). Which isn't good, IMHO, I'd want to encourage people to tell me who they are.
Relatedly, I’m not sure why a RelMeAuth relationship needs to be two-way verified (which is the barrier to twitter working AIUI). Isn’t the auth token from the silo account indicative that the user has access to it?
@jalcine @trwnh yeah and I understand the motivation, but from a practical standpoint it doesn’t meet my needs. If twitter still worked with RelMeAuth I could maybe see it being enough of a lever to get folks to add that to their own websites but it’s still a pretty big requirement to get my depressed friends (many of whom who don’t see the point to having their own website) to have their own website.
Oh yeah my plan for the indieauth profile service was to also provide h-card and (optional) micropub endpoints. :) I wrote more about that on one of my Subl-related blog posts (which I’m short on spoons to find at the moment).
yo so I've been thinking more about this a bit more:
A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!