WeChat ID
aaronpk_tv
-
EdwardHinkle
https://github.com/EdwardHinkle
•
Feb 25
Awesome! Great to hear other areas where this has worked well. Do you have any thoughts between it just applying to channels and it applying to the posts? What does your IRC client do?
(Originally published at: https://eddiehinkle.com/2018/02/25/5/reply/)
I do think it should be a preference, tho maybe hidden by default is okay. The trick is once the channels without new content are hidden, you have to have a way to quickly show them again in case you want to be able to look at old content again.
As for the posts: Slack, IRC clients, as well as Twitter, show all the posts, not just the unread ones. I don't think I personally would use the "show only new posts" feature except in certain cases such as when I suspect there might be some old unread posts that have been buried somehow. I prefer to have some visual indicator about whether a post has been read rather than hiding it completely. In either case, you'd need a quick way to toggle between showing all posts vs showing unread posts. -
My IRC client also does this and it's great
-
at Gnomish BarPortland, Oregon • Sat, February 24, 2018 4:37pm
-
mark posts read button is sometimes missing
I can't quite figure out the circumstances under which this happens, but sometimes the "mark posts read" button is missing even though there are a bunch of unread posts in the channel.continue reading... -
Sandro Hawke
http://www.w3.org/People/Sandro/
•
Feb 22
I want a tool that shows me the top tweets each day/week, judged by RTs and Likes by the people on a list I curate (maybe with weights). Does this exist? Like/RT if you want it, too
@waxpancake did essentially this for himself, and made it public: http://belong.io -
Reading through the @w3c Webmentions spec over morning coffee. https://www.w3.org/TR/webmention/
-
Jonathan Yee
https://github.com/jonyeezs
•
Feb 21
Hi @aaronpk, "oauth-2-simplified" is a breath of fresh air when there are so many ways to do auth. This really simplifies it. I do have a question: Why would i still want to provide my client_secret for server-side when i can do without it to authenticate?
Thanks! It's an additional layer of security. Without it, you need to use additional techniques such as strict redirect URL validation and even PKCE to compensate. -
Nicolás Álvarez
https://twitter.com/nicolas09F9
•
Feb 21
@aaronpk where can I report errors in http://oauth.com?
Feel free to send me an email https://aaronparecki.com/contact -
This is exciting. This will motivate me to work on the multiple destination support I have in mind for my website!
-
EdwardHinkle
https://github.com/EdwardHinkle
•
Feb 20
Yep, exactly. Or a specialized app like Teacup that sends ate and drank posts. Those should still go through regardless.
As you said, @manton, it's more of a suggestion but especially a suggestion for generalized Micropub application, as opposed to specialized.
That makes sense, and also fits nicely with the idea of this as an extension rather than part of the base spec. -
manton
https://github.com/manton
•
Feb 20
@aaronpk I'm glad you mentioned Post Type Discovery, because to me that is the part to focus on. It seems too complicated to require spelling out every property, like category or photo. If an endpoint doesn't support accepting a category on a new post, no harm done.
What can we borrow from the Post Type Discovery spec that will help here? At the very least it seems like the Microformats class names should be consistent.
In my example (https://indieweb.org/Micropub-brainstorming#Query_for_supported_vocabulary) I included what I view as the common actions from an app like Indigenous: like-of, repost-of, and bookmark-of, but bookmarks aren't actually mentioned in Post Type Discovery. I wonder if they should be, or are they not different enough from a regular post to list separately?
Interesting, I didn't actually realize bookmark wasn't in Post Type Discovery. It looks like it was mentioned under "Other Types Under Consideration" before it was moved to the W3C repo. Now the W3C note links to the Kinds of Posts section on the IndieWeb wiki for that.
The way we were adding things to the list of types in the algorithm was roughly based on how well-established the markup was in the wild. I am kind of surprised bookmarks didn't make that cut, but oh well.
The one potential confusion here is that post types are not the same as
h-*types, e.g. there is noh-replybecause you use thein-reply-toproperty onh-entryto create a reply post. I think that just means we need to be explicit about what to call this. To build on your previous example, this could be a solution:{ "post-types": [ { "type": "note", "name": "Note" }, { "type": "article", "name": "Blog Post" }, { "type": "photo", "name": "Photo" }, { "type": "video", "name": "Video" }, { "type": "reply", "name": "Reply" }, { "type": "like", "name": "Like" }, { "type": "repost", "name": "Repost" }, { "type": "rsvp", "name": "RSVP" }, { "type": "bookmark", "name": "Bookmark" } ] }Clients should assume that if it's not in the list, then the server doesn't support it? Of course there needs to be some sensible behavior for servers that don't return this info at all.
Would it make sense to omit
notefrom this list since that's kind of a baseline? Or keep it in the list because it allows the client to customize the name of the button still? -
snarfed
https://github.com/snarfed
•
Feb 20
...also, of course, i've now realized that while this mf2py feature is great, it doesn't actually quite fix this issue, since this is on the consuming side, where i don't control the parser.
@aaronpk, depending on your usage, you might consider asking granary for
format=mf2-jsoninstead offormat=html, since that won't have this problem! i'm guessing you reported this on behalf of someone else who's seeing granary html output in a feed reader, though, so you don't have that luxury either.adding blank
p-nameis totally reasonable. will do.
That's great news! And yes, I was specifically asking for the blank p-name property to be added to the HTML so that parsers that haven't updated for the new implied name parsing rules will still get a result that looks good. -
manton
https://github.com/manton
•
Feb 20
@EdwardHinkle Sounds great! I can implement it at any time on Micro.blog, although first I wonder if anyone has feedback on the JSON key names.
One thing to note is these are all properties of the
h-entryvocabulary, whereas other kinds of posts support totally different properties. Things likeh-eventorh-reviewwhere they are completely different things. Continuing down this path it would make sense to scope these properties to note that they are part of theh-entryvocabulary.The other question is how many of the supported properties would need to be defined? If not all of them, (e.g.
photo,category,published) why these ones in particular?Is it because these correspond with post types? If that's the case, then maybe this should be somehow tied to the Post Type Discovery spec which spells out what properties map to what kinds of posts.
In that case, it may make more sense to have the server advertise which of these post types it supports, and then clients would look at the spec to know which properties to send to create those posts.
