Show more

@jalcine @fluffy ok but what do you do when you want to do something other than following and responding? what do you do when your use case isn't just simple syndication?

@trwnh @jalcine Then whatever those activities are get appropriate extensions to whatever protocol is appropriate. Or add another protocol for the purpose.

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?

@fluffy @trwnh This is what I was thinking to. Most of the actions (if not all) are either "sent" or being queried. It's feeds (or a form of them) all the way down

@jalcine @fluffy interestingly i don't see feeds being the primary analogy here. maybe for managing a website and posting updates, sure, but that's an incredibly limited way of looking at things. how do you handle privacy -- generate a new feed for every possible access group?

@trwnh @jalcine I've written extensively about some proposals for how to handle authentication on Atom feeds. 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
- circles/aspects
- 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.

@trwnh @jalcine I also don't really see the appeal to having everything rolled up into one gigantic uber-protocol.

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...

@trwnh @jalcine oh yeah SMTP certainly does leave a lot to be desired, and I'd love to see something like Google Wave show up again. ActivityPub seems like a pretty good protocol for that use case.

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.

@fluffy @jalcine i do agree that the current problem with activitypub implementations is trying to clone existing stuff. maybe not better done with atom though. for pubsub semantics? sure.

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 Sure, but like, thanks to that legacy, Feed-On-Feeds can follow someone on Mastodon and get push notifications immediately. (Not that I'd want to do that beyond checking to see if it works, as the UX is *horrible*.)

@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.

@fluffy @jalcine well, as i've commented on a blog post of yours before, that is a nice thing :) mastodon at least publishes both rss and atom feeds, as well as json.

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 That's fair! I think my main frustration with AP right now is that I'm trying to support AP via Publ without having to implement a full AP stack, and bridgy fed does a great job of supporting AP-the-protocol but that doesn't necessarily match with AP-the-stacks-in-common-use.

@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, maps (on my site) to - 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.

@fluffy @jalcine resource@domain is not really an activitypub thing, that's a webfinger thing. activitypub uses https uri for everything, e.g.

@trwnh @jalcine Ah, okay! I wasn't really clear on that, since at least Mastodon and Pleroma only seem to support the Webfinger mechanism of discovery/following/etc.

@fluffy @jalcine i actually kinda hate webfinger but unfortunately the standard reasoning seems to be "most people understand it because it's similar to email"

like is there a difference between typing or 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.

@fluffy @jalcine indieauth is definitely justified i think. openid sadly seems to be dead, but isn't there openid connect (oidc) though? that's vaguely based on oauth iirc

@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

@fluffy i do certainly wish that there was a more universal identity provider, like, if oid1 had actually taken off. its promotional website reads like a dream...

@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

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 emit the kind of profile info you'd see if you did a GitHub OAuth2 dance (by way of fetching someone's or merging silo info). Which isn't good, IMHO, I'd want to encourage people to tell me who they are.

@jalcine @trwnh and that’s why I’d still rather have my own auth stuff be able to use a twitter url directly - what if what people are is β€œyour friend from twitter?”

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?

@fluffy @trwnh this makes it too specific to a silo, platforms that we don't control. The idea of indieauth, at least from the social stance, is not rely or lean solely on a silo for identity

@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.

@fluffy @trwnh that's fair, I guess. I'm forcibly adding support for Twitter by using their mobile intent pages. But yeah, I think it's a hard sell to move people. It's something they have to choose


@jalcine @trwnh yeah and at least with a generic identity provider like launchpad or whatever, they can use a trusted side channel to tell me who they are.

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).

Β· Β· Toot! Β· 1 Β· 0 Β· 1

@fluffy @trwnh (soon I'll have some sort of AP support by way of bridgy lol)

Sign in to participate in the conversation
Queer Party!

A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!