#gRegor`!tell snarfed Thanks for the u-url updates on brid.gy! I've got multiple webmentions (comment + like) displaying together now: http://gregorlove.com/2014/01/1178/#w9
lukebrooker, wtd, ScruffyDan and snarfed joined the channel
#Loqisnarfed: gRegor` left you a message 2 hours, 27 minutes ago: Thanks for the u-url updates on brid.gy! I've got multiple webmentions (comment + like) displaying together now: http://gregorlove.com/2014/01/1178/#w9
KartikPrabhu, dybskiy, lukebrooker, dybskiy_, snarfed and gRegor` joined the channel
jsilvestre, tobiastom, KevinMarks, LauraJ, Jihaisse, eschnou, fmarier, nloadholtes, krendil, petermolnar, Sebastien-L, glennjones, adactio, zaal, pfefferle, friedcell and tantek joined the channel
#Loqitantek: barnabywalters left you a message 12 hours, 44 minutes ago: also spotted whilst feed testing: errant trailing slash in <a> on line 233 of your homepage, and no photo property on the h-card
#tantek!tell barnabywalters my content is posted in pacific time zone
#tantek!tell barnabywalters errant trailing slash in u-url for h-feed fixed. figuring out a photo/logo for my homepage h-card will take a bit more work / redesign / remarkup. -t
wtd, glennjones, pbeaulieu, pfefferle, tantek and barnabywalters joined the channel
#Loqibarnabywalters: tantek left you a message 1 hour, 27 minutes ago: my content is posted in pacific time zone
#Loqibarnabywalters: tantek left you a message 1 hour, 26 minutes ago: errant trailing slash in u-url for h-feed fixed. figuring out a photo/logo for my homepage h-card will take a bit more work / redesign / remarkup. -t
#barnabywalterspretty sure there’s no way to determine the timezone from the markup on your site — might be an idea to add timezone information in there
#barnabywalters!tell tantek RE timezone info, I can’t find a way to determine the timezone from the markup on your site, so you should add timezone information in there somewhere otherwise consuming apps are going to assume that it’s UTC
#barnabywalters!tell tantek unless of course we want to spec out a timezone-implying algorithm based on geo lookups of data given in your h-card — likely to be complex overkill though :)
#Loqitantek: barnabywalters left you a message 10 minutes ago: RE timezone info, I can’t find a way to determine the timezone from the markup on your site, so you should add timezone information in there somewhere otherwise consuming apps are going to assume that it’s UTC
#Loqitantek: barnabywalters left you a message 10 minutes ago: unless of course we want to spec out a timezone-implying algorithm based on geo lookups of data given in your h-card — likely to be complex overkill though :)
#tantekbarnabywalters: no it's definitely a content problem on my end
#tantekat a minimum Falcon should be fixing up the datetimes with explicit TZ info so that cosuming software doesn't have to guess at anything (or errantly assume Z)
#barnabywaltersif you continue to use split date/time parts using value-class it’ll be another good test case — not sure I’ve ever seen separated date/time/timezone dates in the wild
#tantekindeed - I may put TZ info into an abbr too
#tanteknot sure why you'd want to cap future dates to the present either
#tantekI use future dates as a delayed posting mechanism
#barnabywalterstantek: this is for a reader — allowing posts to be in the future would allow people to “stick” posts permanently at the top of your timeline by setting the date to 9999-12-30
#ben_thatmustbemeI tend to use local time for posting (human verify) and that is the date that is indexed/how the URL is define, thought the date stored and date shown in timestamp for a post is in UTC (ISO8601). Displaying timestamps for events upcoming would certainly be something that should be in the local time for the event though
#tantekben_thatmustbeme: a bit of out of order in the IRC messages there. ISO8601 is fairly intl friendly (aside from the long form written unreadability). it's RFC(2)822 style dates that are not intl friendly.
#tantekmight be a bug on the part of the publisher
#ben_thatmustbemebarnabywalters, i think tantek is correct, hiding them would be best. legitimate future posts markup should never reach a reader, and thus if it gets one its probably better to discard (hide)
#tanteklike accidentally publishing a future post that shouldn't be shown
#barnabywalterstimezone bugs are exactly why I was going to cap them to the present
#KartikPrabhushould indieweb readers also do calendar things? like event reminders? then future posts woiuld be of use
#barnabywaltersand there’s little point hiding things which can be seen by going to a public URL
#tantekbecause you don't know why they're in the future, better to just discard rather than show
#barnabywaltersit’s confusing to not show things which are there
#barnabywalterstantek: all the reader knows is that they’re marked up in the feed
#ben_thatmustbemetrue, but as you pointed out, sticking them to the top isn't right either, perhaps just use current timestamp if it is in the future
#barnabywaltersben_thatmustbeme: that’s exactly what I mean by capping it to the present
#barnabywaltersKartikPrabhu: calendaring and inline RSVPing is on my roadmap
#ben_thatmustbemebut then what do you do with it after that (if someone corrects the error)
chrissaad joined the channel
#tantekben_thatmustbeme: exactly, that's why it's better to ignore at first
#tantekbarnabywalters: the reason to hide it, despite it being visible at a public URL, is to provide a better fidelity (higher signal to noise ratio) experience
#tantekbetter to just ignore them than try to "fix" them
#ben_thatmustbemei don't like ignore, it would be extremely frustrating for a user if their favorite site has a bug that has timestamp format incorrect (switching days and months for example)
#tantekKartikPrabhu: is exactly right. e.g. my design for my own event posts involves storing them at their dt-start date and time which likely means the future
#barnabywaltersgiven that this has not yet happened, I am hesitant to make destructive decisions without actual real world examples
#barnabywaltersben_thatmustbeme: exactly, which is my rationale behind “show what is there”
#barnabywalterstantek: events are completely different from posts
#ben_thatmustbemebarnabywalters, what about error message and setting
#tantekfor those that want to see all the "bugs", then keeping future posts floated to the top is a good way to indicate a problem that they can then use to contact their favorite site and get fixed.
#barnabywalterstantek: events == h-event == should be in the future, posts == h-entry == should not be in the future
#barnabywalterstantek: I have no intention of ever capping event datetimes
#tantekben_thatmustbeme: nope, not mixing, just using "events" as an example post type about how a "dumb" feed reader can't assume anything about future posts.
#tantek"dumb" meaning feed reader that only explicitly knows to handle generic things about posts like a note or article would have
#barnabywaltersand has a dt-published property from the time benwerd clicked “publish”, but a dt-start property about the actual event
#barnabywalterstantek: I totally want to make Shrewdness be future-post-type-friendly, but also want it to be robustly predictable
#barnabywalterswhich in the case of posts with a published datetime set in the future, IMO should mean capping that to the present and showing them
#ben_thatmustbemeso forget about what type of post it is, focus on the single aspect of "what do you do if you are consuming an 'item' with a date 'published' in the future". I think it obvious that no matter the type, a date published in the future is an error. Discarding leaves things too confusing for the user, just displaying at top allows for one erroneous site to take over the feed completely, and displaying with a current timestamp might cause
#ben_thatmustbemeI think from those options, if you are going to default to (or only have one) way to handle it displaying by current timestamp seems best
#barnabywaltersben_thatmustbeme: yep, all of those cases are undesirable, but IMO showing the data which is there is less confusing and more robust
#ben_thatmustbemefrom UI perspective, i would default to that but also have it note that there is an error, and have a setting to select any of those 3
#barnabywaltersben_thatmustbeme: I’m certainly going to expose the information somewhere in the UI, along with the given date (if for example it *is* the datetime of an event), might also allow the user to pick what behaviour is applicable
#barnabywaltersreally need to see an example of this in the wild though
#ben_thatmustbemegood luck with finding that, i can't see it being too common
#ben_thatmustbemeperhaps if the TZ info isn't published and it gets assumed to be UTC that could happen
#gRegor`!tell tantek This is minor, but I'm confused by this on this week's HWC page "Note the Minneapolis meeting is at 19:30 CDT (will sync with PDX and SF at 18:30 PDT)" Meaning the second hour will sync up with PDX/SF?
snarfed, pbeaulieu, emmak and luxagraf joined the channel
#npdotyI'm not sure when the gray box was added to the indiewebcamp.com front page, but I think these three positive statements are really great (your content is yours
#Loqitantek: gRegor` left you a message 2 hours, 35 minutes ago: This is minor, but I'm confused by this on this week's HWC page "Note the Minneapolis meeting is at 19:30 CDT (will sync with PDX and SF at 18:30 PDT)" Meaning the second hour will sync up with PDX/SF?
#gRegor`@shanley is trying to export her content from medium.com and running into problems. Sounds like it might be technical problems, but still another good argument for POSSE.
#gRegor`aaronpk: She's been getting a lot of harassment from reporters
#gRegor`And, well, just a lot of people in general
#tantekgRegor`: if shanley is running into problems trying to export her content from medium.com then I fully expect to see a medium.com post from her about those problems.
#KartikPrabhuhmmm where I have i heard of @shanely before....?
#aaronpkoh sorry I should have put that comment in #indiechat
#snarfedtantek: yeah, that's what i saw too. silly
#tantekfinally it loaded one time without showing as being favorited, so I favorited it again, reloaded, and suddently it showed my icon, count was updated
#tantekbigbluehat: going to be difficult to change existing browser UI in response to email addresses in URL bars, since it doesn attempt to do something (login)
#snarfedi deployed your latest PR just now, so that's good validation
#tantekbut I will agree that the current behavior is annoying/disappointing
#KartikPrabhuwasn't expecting the log in behaviour... remenants of ftp UI?
#tantekregarding obviating gravatar, I think we did that already with hcard and personal domains.
#snarfed"repos zero" was a badly oversimplified joke
#tantekis aiming for useful Twitter differentiation zero.
#snarfedbut there's a kernel of truth too. working in public, definitely. but ongoing maintenance for an ever increasing set of projects can become unsustainable
#tantekkylewm I'm just having trouble understanding how the term "mult-repost" makes any sense
#kylewmtantek: I'm not married to it. aggregation, collection, etc. are more accurate
#tantekalso this post: https://kylewm.com/share/2014/04/14/1 *embeds* a *list* (apparently datetime ordered) of other posts, and adds a line of new content as well: "I was reading some of ..."
#kylewmtantek: oh cool, I didn't realize it was considered a comment on Tumblr, comment on your own blog POSSE to the other, that's very indieweb for all being inside a silo :)
#jonnybarnescos myhouse connection doesn't, and my little pet project tonight was getting my site accessible over IPv6 considering v6 addresses are free
#jonnybarnesI think I;ve got it set up but obviously I can't test it