Another successful Guerrilla Happy Hour with @alexshred420 and many, many friends. Here’s to another seven years of paying people to drink with us.
WeChat ID
aaronpk_tv
-
-
-
Tickets are STILL AVAILABLE for the Portland show on 3/30 and Seattle show on 4/1! I requested that the venues not advertise these shows until the end of the day so that my fans can have first dibs! #CrazyExGirlfriend
-
I don't like running things in Docker so I won't be tackling this, but I'm open to accepting a PR if someone puts it together.
-
Zegnat
https://github.com/Zegnat
•
Feb 16
It doesn’t return the Microformats JSON, it converts it to its jf2 format first.
It might be worth opening an issue on jf2 to see if they want to keep an explicit
nameproperty. Their “author” syntax says it “consists of a name” and more, but that’s not marked as a MUST. For a jf2feed on the other handnameis a SHOULD.The real question is, do you see any reasons for postponing this change because of your use of a mf2 parser as a service? I think not?
Nope, wasn't intending to hold things up, just wanted to put that there for the record.
I agree with the current proposal of having
p-*ande-*andh-*stop the implied name. -
Zegnat
https://github.com/Zegnat
•
Feb 16
Documenting from yesterday’s chat, because nobody could remember this and I can’t find it elsewhere:
- @tantek would like to keep parser changes conservative but is “amenable to expanding to any p- or e- = no implied p-name”.
- I have not been able to document any cases where more than this is necessary either.
So I think the (as of now) latest proposed spec change would be:
p-nameMUST NOT be implied if there are any explicitp-*ore-*properties, or any nested microformats.
Currently all mf2 items have a name property, because of implied name. If we change this, some code using the parsers could fail if it assumes a name is present.
Here too I will just document an answer given in chat, this time by @aaronpk:
may just mean it has to be released as a major version number [of the parsers]
Assuming something like semver is being used, any major version bump should signify possible API changes to the user. I too don’t think that would be an issue.
There might be an issue if someone is using parsers-as-a-service, e.g. always getting their mf2 parser output from
php.microformats.io. But I don’t think anyone ever advertised their online parsers as a service?
I (and likely others) use xray.p3k.io as a service, so I will have to consider what to do in that case. It doesn't return the Microformats JSON, it converts it to its jf2 format first. I may just return an empty string for
nameif there is no mf2nameproperty. -
Great followup post!
> I'd like to explore building a simple iOS application to remove any friction from posting updates on the go.
If your site supports Micropub (https://www.w3.org/TR/micropub/), then you can use any number of Micropub apps to post to your site, instead of writing them yourself! In fact, there's already a fantastic start to an iOS app for exactly this purpose, called Indigenous, in beta right now. https://indieweb.org/Indigenous It should be a minimal amount of work to create a Micropub plugin for Drupal, and then you can take advantage of everyone else's work building clients! -
-
-
A lot of progress is happening on the Together project. Its shaping up to be an amazing Indie reader! New features include responsive design, read/unread tracking, "classic" view, and more. Great job, @grantcodes – https://cleverdevil.io/s/rbTFxamOAH.mp4
-
-
I just updated the text to hopefully be more explicit about this: https://indieweb.org/Microsub-spec#Set_Channel_Order
