#dev 2022-08-08
2022-08-08 UTC
alex11, GWG, nertzy and geoffo joined the channel
# 
[snarfed] angelo omz13 sounds reasonable. indie map has >1100 sites with h-cards at least somewhere, https://indiemap.org/docs.html#mf2_by_sites , but maybe fewer if you only looked at home page
# [snarfed] and if you can formulate representative h-card as SQL, you can query indie map directly: https://indiemap.org/docs.html#data-mining
gRegor, angelo, gxt___, tetov-irc and [jgmac1106] joined the channel
# 
@TheDavidDias ↩️ @killianvlt @Uzoway_ thanks for being part of the experiment, as I'm adding Webmentions to my blog, I can see it's… https://twitter.com/i/web/status/1556608295590322177 (twitter.com/_/status/1556608295590322177)
# IWDiscordGateway <capjamesg> [campegg] I have added Micropub to Flask before but not Django.
# IWDiscordGateway <capjamesg> I'm happy to help how I can though.
geoffo and [campegg] joined the channel
# [campegg] [jamesg483] Thanks! I’m having a bit of a re-think about Micropub at the moment. It probably falls more into the nice-to-have bucket, so am going to tackle some of the million other things on my site to-do list first. But I did have a bit of a poke around https://github.com/capjamesg/micropub to see how you did it 😉
# [campegg] capjamesg++
# 
@kilianvalkhof ↩️ I think a good point can be made for webmentions being more higher value and less problematic compared to traditional "comments". (twitter.com/_/status/1556669055624437763)
# 
@swyx ↩️ haha you know im a fan. but webmentions also have a spam issue. and not supported by 99% of blogging platforms (twitter.com/_/status/1556669368834088966)
[aciccarello], gRegor and [chrisaldrich] joined the channel
# 
[chrisaldrich] I converted/promoted a WordPress tag into a category which changes the URL/path of some posts as well as potentially the feeds for that category. I've done a 301 redirect for both, but is that the best technical option (particularly for the feed) or should I also do something else?
# [chrisaldrich] I feel like it's not a typical pattern for people to redirect feeds in general, but more probably ought to to retain subscribers instead of them needing to resubscribe or fix things on their end? What else might publishers do to make this easier for their readers?
# [chrisaldrich] I know a few anecdotal examples of writers who change URLs every few years and start rebuilding their readership for RSS from scratch and this seems like something folks don't think about at all or even think through. Anyone have examples of this pattern and the best way(s) to handle it?
# [chrisaldrich] I know that WordPress.com will charge you an annual fee to redirect readers to a new site. (I recall it being on the order of $12-15/year about five years ago, so it's at least a service they offer.)
geoffo and mlncn joined the channel
# 
[tantek] (copied from #indieweb-meta) There's also I think the counterpart, which for lacking a better name, I suggest "aggregation policy", which is where you can document how you bring in content from other sites to display e.g. in reply-context on your /reply posts or link-previews, or /response posts in general
# [tantek] (copied from #indieweb-meta) e.g. if someone sees their icon, or their fully quoted tweet on your site, describe your intention to respect/honor their wishes, and how they can ask for removal from such a reply-context etc., or how they can ask to opt out of ever having their otherwise public (e.g. public tweets / twitter icon) information show up on your site
# [campegg] I like the concept of an “aggregation policy” — you’re right it’s not as good as a blanket opt-out, but definitely better than nothing.
# [campegg] How does something like a retweet fit here? It’s not really a reply… is it more of a (reverse?) syndication? Would we be able to wrap that up under whatever aggregation policy we land on?
# [tantek] GWG, you need one of these: https://indieweb.org/display-guidelines
# 
Loqi It looks like we don't have a page for "syndication policy" yet. Would you like to create it? (Or just say "syndication policy is ____", a sentence describing the term)
# [tantek] syndication policy is /display-guidelines
# [tantek] GWG, you want /display-guidelines
# Loqi remote content policy is a form of disclosure by a site about how it may treat content received (federated) from other sites, like how it may by default treat messages from other sites with URLs, from new remote accounts, with images or video, and/or from known abusive sites https://indieweb.org/remote_content_policy
# [campegg] 🤔 “aggregation policy” seems like a clearer (or at least, more understandable) description of what we’re talking about than “remote content policy”
# [campegg] Also wondering if there’s a convention around wrapping some of this stuff up into a single page so we don’t end up with policy-itis… having a bunch of separate pages for all of this seems a little over the top for a personal site
# Loqi ok, I added "suggested alternative (clearer & shorter) name: "aggregation policy"" to the "See Also" section of /remote_content_policy https://indieweb.org/wiki/index.php?diff=82722&oldid=82719
gRegor joined the channel
# [campegg] You might be right there — having them separate would likely make it easier for someone to locate the specific info they’re after. But having a bunch of different pages for policy-type info just doesn’t sit right with me in the context of a personal site; seems kind of… corporate-y, I guess
# 
[schmarty] If it gets confusing in that way it might makes sense to make a wiki category to unify them
# [schmarty] Might be a problem for later when the pages are more filled out though
mlncn joined the channel
# [tantek] campegg, I looked up the origin of "remote content policy" and it's a now defunct page. Added an explicit suggested alternative names section to see if this is something we can quickly agree on is better for the IndieWeb and move forward accordingly: https://indieweb.org/remote_content_policy#Alternative_names (please add your preference/opinions)
# [tantek] re: separate pages vs one unified page. based on the existing lengths of some of the topic-specific policies, I feel just for discoverability / readability / IA it's worth keeping them separate *and* providing easy navigation amongst them (especially perhaps a sequential navigation if you want to just "click through" and read them all one by one)
[tantek]1, [schmarty]1, IWSlackGateway5, stevestreza, benji_, walkah_, Kaja_, rhiaro, [tantek]2, jjuran_ and lagash_ joined the channel
# [campegg] That makes sense… I personally don’t love the idea of having a bunch of different policy pages, but I do agree with your underlying premise
bradenslen, [schmarty] and [chrisaldrich] joined the channel
[aciccarello], AramZS, Wurglebiscuit, moose3337, jbove_ and Steve[m]1231 joined the channel
# [campegg] gRegor separate pages on a personal site. Totally fine with multiple wiki pages
# [campegg] And likewise
neceve joined the channel
# [campegg] At least, that’s would be my preference, but [tantek] makes a good case for having them separate
Seirdy, AramZS, geoffo and tetov-irc joined the channel
# [tantek]2 gRegor, it's grown enough on our wiki, and the examples are dissimilar/divergent enough to be worth documenting on separate wiki pages
# [tantek]2 separately (so to speak) I also think it's a good idea to capture these kinds of policies/guidelines in tightly topic-focused formats for better readability / clarity
# [tantek]2 it's also reasonable to "throw them all on one page" with headings / fragment links for each in a section, and then let them evolve and if/when necessary, break out individual sections into their own pages, leaving a summary behind
# [tantek]2 that way we can provide reasonable paths for "keeping all policies on one page" *and* one page per facet / aspect of policy/guidelines
# [tantek]2 GWG, I'm getting "they don't even know" meme vibes from that 😂
# [tantek]2 :thumbsup::skin-tone-2:
nertzy joined the channel