[tantek][snarfed] is there an AP or other method in Mastodon to indicate pinned posts so they show up when someone views your profile on their own instance?
Loqi📌 pin or pinning is a feature that allows the author to choose a post to put at the top of their profile (or homepage) which is then called a pinned or sticky post https://indieweb.org/pinned
[snarfed][tantek] I haven't looked into pinned posts at all. afaik they're not explicitly in AS2/AP, but there might be something in the JSON anyway, I can look
[tantek]First thought is perhaps a u-pinned-on property inside h-entry that's a URL of the page the post should be pinned on if/when displayed on that page.
LoqiIt looks like we don't have a page for "stick posts" yet. Would you like to create it? (Or just say "stick posts is ____", a sentence describing the term)
LoqiIt looks like we don't have a page for "sticky posts" yet. Would you like to create it? (Or just say "sticky posts is ____", a sentence describing the term)
Loqi📌 pin or pinning is a feature that allows the author to choose a post to put at the top of their profile (or homepage) which is then called a pinned or sticky post https://indieweb.org/sticky
[pfefferle]There is also a collection to have featured (hash)tags, but it is not really well documented and my first try produced a lot of 500 errors on the Mastodon UI 😞
[snarfed]definitely poetic. yeah AP and IndieWeb are both combinations of push-style message passing and pull-style data fetching, and both center domains and SSL in their trust models
[tantek]pin << Software Support: [[Mastodon]] has pinned posts on [[user profile]]s that they support communicating and displaying across instances by extending the [[ActivityPub]] "actor" object with a "featured" property that has a URL to a collection of posts which have been pinned by that actor (author) to their profile. https://docs.joinmastodon.org/spec/activitypub/#featured
[snarfed]security is hard, everything has vulnerabilities, nothing is perfect. it's pretty rare that any single type of vulnerability should disqualify an entire class of systems/solutions
[tantek]exactly [snarfed]. if you're thinking about security in any absolute terms (secure/insecure), instead of measuring/estimating time, effort, layers (defense in depth) or other resources necessary (barriers being raised) to overcome, you're thinking about security in a simplistic and likely very incorrect way.
[tantek][snarfed] curious what you think of the u-pinned-of brainstorm (as noted last night in chat: https://chat.indieweb.org/dev/2023-12-29#t1703814447760500 ), and making "pinning" a property of individual posts, rather than a property of a h-feed or an h-card for that matter (the apparent path that Mastodon took with extending "actor").
[tantek]they key reason for the different approach (and a URL property rather than a boolean) is posts that want to be pinned (or not) differently in different contexts (homepage, tag feed pages, perhaps archive pages,e tc.)
Loqi[preview] [[tantek]] First thought is perhaps a u-pinned-on property inside h-entry that's a URL of the page the post should be pinned on if/when displayed on that page.
[tantek]pretty sure aaronpk's examples (and all the rest on /pin#IndieWeb_Examples) could be represented (published) that way, so the larger question is would that work reasonably for consuming code, or be too hard to make work
[tantek]Or, since BF works via webmention from individual post permalinks, u-pinned-of on that post permalink should be sufficient to do direct discovery
[snarfed](BF would only need to crawl all posts if it needed to discover a given feed/card's pinned posts, and that was only available per post. I definitely don't actually want to do that)
gRegorI don't know the AP side of it so maybe I'm off, but I publish a post with u-pinned-of, send a wm to BF, BF uses that property to set the pinned flag when delivering the post
[snarfed]but again, when BF sees a new site, if pinned-of was per post, BF would have to crawl every post on the site to correctly know which posts are pinned where
[snarfed]sure. apart from mental model, maybe the more important thing is, I still don't think I've heard an actual external consuming use case for pinned on posts instead of feeds
gRegor[snarfed], yeah, I think we're agreeing :) I guess I'm confused though, is BF going to change so when someone signs up it federates their last X posts, and will include pinned posts if they exist?
[tantek]yes Social Readers could either ignore the pinned aspect/property of posts, OR, optionally, if a Reader implements a "profile" view (which frankly I think Readers should, since we should be following people, not feeds, in the UI/UX), then it could *optionally* display the pinned posts as part of that profile view
[tantek]1 already on BF, the current (normal) user flow is, publish a post, webmention Bridgy from that post permalink. add to this: BF checks for u-pinned-on property on that post with value of the homepage of that user. if that exists, then BF adds it to the profile of that user and sends a profile update to Mastodon followers. if not, then BF checks the profile of that user to see if that post was pinned for that user previously, and if so,
[tantek]2 new user on BF, sets up their profile as is their current (normal) user flow, and shows zero pinned posts. this is ok, this is expected/current behavior. if the user wants to then show/pin posts on their personal site and propagate them to Mastodon profile views, they opt-in webmention BridgyFed directly from those pinned posts as in (1)
[tantek]if you are using BF, you already have to do "additional work" of linking to fed.bridgy from your post permalink(s) so that the webmention works. adding another u-pinned-on link is basically the same kind of step, except you only do it on pinned posts
[tantek]right, so same problem/opportunity then. until BF is auto-federating everything in your h-feed when you sign-up, there is no need to worry about auto-federating already pinned posts on your home page when you sign-up
[snarfed]it sounds like this comes down to the difference of mental model. do you see pinned posts as a) integral to a user's profile/feed, and should always appear with that profile? or b) somewhat optional, visible if eg the user has "pushed" them via wm, or if they've been federated to your instance by another trigger
[tantek][snarfed] I would argue that (b), that is, the "only subsequent actions/posts matter" mindset is exactly how ActivityPub is designed, with zero consideration for history, archives, etc.
[tantek]even if that's not how we think of "classic" feeds, blogs etc., where the presumption is you show up, or subscribe to a feed, and you immediately see old/recent stuff
[tantek]another piece of evidence: the fact that identity migration is a thing, and folks got working first, on Mastodon, and have not yet figured out post migration (the past)
[snarfed]we're agreeing violently. yes that's the status quo; doesn't mean it's the best or least surprising design. it's also not universal, eg it's not necessarily the web philosophy, and BF is multi-protocol
[tantek]snarfed, if you want a happy medium/compromise that involves zero additional crawling, BF could check for u-pinned-on properties only directly on posts in the user's homepage h-feed
[snarfed]in any case, I still see a meaningful difference in mental models. I understand that you all expect and are comfortable with b. I guess I'm still not yet, it feels like an unpleasant surprise. pinned posts in my mental model (a) are just as much a part of the profile as they are standalone posts
[tantek]because presumably, if a user has pinned posts on their homepage, those posts are also in their homepage h-feed, and thus should include the explicit u-pinned-on markup.
[tantek]including the brainstorm "how to markup" and then I'll bug gRegor and aaronpk to consider experimenting with publishing the markup, since I know gRegor is a BF user, and aaronpk can then decide if he wants to implement that Masto AP "featured" collection on "actor" himself
[tantek]next meaningful step is documenting the brainstorm on the wiki so we have something we can link to, to make sure we are talking about the same thing!
[snarfed]it is still interesting that historical precedent of at least Mastodon and iirc Twitter, and I expect others, is to put this on the profile, not the posts. we'd be diverging from that
[tantek]yes I already noted that because we have more/broader IndieWeb use-cases for pinning than the simplistic Maso/Twitter use-case of "pin means on your profile"
Soni we're glad we didn't use headers for fedilinks heh
Loqi 📌 pin or pinning is a feature that allows the author to choose a post to put at the top of their profile (or homepage) which is then called a pinned or sticky post https://indieweb.org/pinned
[tantek] Some considerations in https://indieweb.org/pin#Brainstorming and apparently [KevinMarks] saw a "pinned" Boolean in the Masto API
[pfefferle] I have implemented pinned posts for the WordPress plugin too!
jacky this is a very fair assessment of AP (from the few times I've tried implementing it) https://hachyderm.io/@hrefna/111662739576534724
[schmarty] s/blame/credit/ ✨