Meta Requirements

[grantcodes]

Hey all,

I figured it would be good to start a community project by defining some goals, which can then be spit out into separate issues at a later date. I will keep this list at the top updated based on feedback.

This thread is for meta related stuff, so not direct code or implementation ideas, but issues around management, testing, deployment, documentation, community etc. Technical requirements are in #2

• [ ] Full test setup
• [ ] Good documentation
• [ ] Contributor guidelines (bug templates etc)
• [ ] NPM module
• [ ] Continuous integration or something to automatically run tests and deploy to master
• [ ] Multiple people with admin access to everything
• [ ] Decide on node version support (current lts is probably enough in node world)
• [ ] Create a template repo based on the findings of this repo that can be used for other endpoint projects
• [ ] Add to the indieweb github org
• [ ] Add a licence (MIT suggested)
• [ ] Minimal dependencies where possible

[grantcodes]

So for an npm module I own the @indieweb organization on npm so I suggest we make use of that for this and any future collaborative projects.

[miklb]

I've recently taken a deeper dive on documentation and contributor docs for open source projects and can commit to helping on those as I improve my Node skills.

[paulrobertlloyd]

So for an npm module I own the @indieweb organization on npm so I suggest we make use of that for this and any future collaborative projects.

Nice! This was one of the things I was going to suggest. I’d suggest packages published under this organisation have the following properties:

• Developed openly and collaboratively (assumed, but worth restating)
• Independent of any particular IndieWeb project or implementation
• Are up-to-date with the current IndieWeb standards
• Keep dependancies to a minimum
• Share the same licence (MIT?)
• Extensible
• Tested

I’d also suggest packages under this namespace attempt to do one thing, and one thing well. The @indieweb organisation could almost be a badge of quality/assurance.

I have few suggestions of the sort of packages I imagine existing under this organisation namespace, but I‘ll open separate issues for these.

[grantcodes]

I'm in total agreement with you @paulrobertlloyd

I'll add your ideas that aren't already there to the checklist at the top

[grantcodes]

I'll also add a note here saying that I started this repo with the idea of perhaps developing a community micropub endpoint, and I chose the micropub endpoint purely because there seems to be the most interest around that. And then from one example project we could expand to others following a similar methodology,

But a micropub endpoint is not the simplest indieweb building block. So it may be more prudent to start with something simpler (e.g. token endpoint, token verification or post type discovery). Especially because I think the existing code for those are basically already done to a high standard and could easy be reused by anyone. And then we could follow with best practices from there.

[paulrobertlloyd]

@grantcodes I think because people will want to build different things, the most value would come from collaborating on common micropub building blocks that are well defined, agreed upon and would benefit from being supremely well (battle) tested.

Much of my time is spent trying to understand and fix issues the result of malformed/unusual requests that different clients might send – if that effort were centralised, it would make building an endpoint much easier.

But I also think there might be some value in documenting common patterns – things that are probably too small to be made into packages (at least initially), but might be common stumbling blocks. For example, how to derive content, photo, slug and published properties from a request and correctly format the resulting mf2. Maybe that’s something we can do on the wiki in this repository, or on the main IndieWeb wiki?

[martymcguire]

In terms of low-hanging fruit, micropub client building blocks would be my preference. I want to see a thousand weird micropub clients bloom! Post panoramic photos to your site! Checkins without Swarm! A dozen photo filter apps that each only do one Instagram or Snapchat filter before posting it to your site, etc.

I had the thought over and over while building Kapowski that some Express middleware and some form-handling libs that make it easy to say "just micropub this stuff please" to make the actual requests would make it really fast to get to the interest parts of these client apps.

All that said, I agree that making more and better micropub endpoint components will lead to more folks building them for more interesting platforms, leading to more folks actually using micropub clients to post to their site, so it's win-win.

Thanks for getting this started!!

[grantcodes]

The thing with clients @martymcguire is that the tech for creating building blocks is way more complicated & fragmented. And then even if you make a frontend, you also probably need some sort of backend as well because micropub endpoints generally do not support cors requests.

I have my react components and micropub helper as sort of micropub client building blocks. But not everyone (fairly) wants to use react.

TLDR: reusable node backend is far easier than javascript frontend

[voxpelli]

What I think we need

• collaboration
• interoperability

What I don't think we need

• "official" IndieWeb libraries (any such "official" library should be maintained by the community at https://github.com/indieweb/ and should only be maintained collaboratively of it's a critical component that lacks a main maintainer and thus needs the community to step up)

Why?

Well, I think the IndieWeb principles of selfdogfooding, plurality and modularity precludes the creation of "official" one-module-to-rule-them-all kinds of projects.

The fact that we eg. have multiple micropub endpoints are great! The lack of collaboration between them and thus also any possible lack of modularity and interoperability is less great 🙂

Focus for this group

I would propose that this group focuses on stuff like:

• Could eg. a media endpoint implementation be built and integrated independently of many of our micropub endpoints? So that it could be used with my endpoint as well with someone elses?
• Could the formatting of a post from mf2 data to eg. Jekyll format be something that we could share? If so, what API would such a module need?
• It seems like @glennjones' microformat-node has been untouched for 2 years. That's a fairly critical component for the javascript community. Can we step up and maintain it as a community? (Then at https://github.com/indieweb/)

Inspiration

• The PHP-FIG group (Framework Interop Group) creates standards that frameworks and libraries can add support for without the PHP-FIG really providing any code of itself. It then publishes standard interface definitions at https://packagist.org/packages/psr/
• abstract- npm modules that defines an API interface and implements a reusable test suite that can verify compliance with that API interface. See eg: https://www.npmjs.com/package/abstract-blob-store and https://www.npmjs.com/package/abstract-chunk-store

Taking inspiration from those two we could eg. create modules like abstract-mf-formatter or similar and providing a test suite and a badge like:

Such a thing I think would be a good idea to publish at @indieweb/ on npm, then any non-abstract implementation would have its home outside of that organization I'm thinking.

What do you all think?

[paulrobertlloyd]

While I don’t think there should be an official micropub endpoint project under @indieweb organisation – let a thousand flowers bloom – I do think there’s a role for common, tightly scoped, foundational npm packages to be hosted under that namespace.

As to the indieweb GitHub repo, it currently features no Node-based projects (most are of the PHP or Ruby variety). For those of us building IndieWeb projects with Node, our aim should be to change that :-)

As pointed out, there are already a few foundational packages that are no longer being actively maintained. So perhaps updating and collaborating on updates/refinements to these packages would be a good place to start, moving them to IndieWeb namespaces should their authors be willing.

[grantcodes]

Everything here sounds like a good idea to me.

I think there might be an argument to be made that micropub-express could count as a abstract module, but definitely if the smaller pieces are under the indieweb name then that is more than good enough to me!

I am not sure if there are any requirements written down anywhere about when projects can be moved to the indieweb gh org, but I think the main reasoning was it was used by more than multiple people / projects. But I think it would be fine to develop them in personal repos until they are ready and then move them over.

NPM is a slightly different case because I don't think we want to have a lot modules that then are deprecated and moved to the indieweb org. So I would suggest once they are ready they can be pushed to the indieweb org if multiple people are planning on using it. Or something along those lines. Sound fair?

[paulrobertlloyd]

NPM is a slightly different case because I don't think we want to have a lot modules that then are deprecated and moved to the indieweb org. So I would suggest once they are ready they can be pushed to the indieweb org if multiple people are planning on using it. Or something along those lines. Sound fair?

Might be worth investigating how people writing composer packages for PHP handle using the indieweb organisation on packagist.

[grantcodes]

Asked about publishing to orgs in the chat: https://chat.indieweb.org/meta/2019-07-29#t1564403333542900

[miklb]

Just wanted to thank y’all for the discussion on this subject. I think having the modules in IW repo helps with a few things. One, if folks move on it is easier for new people to adopt & maintain rather than having to fork. Two, while I’m also hesitant of “official” monikers and a monoculture, I’m more leery of projects that are in personal repos that don’t allow broader perspectives. As someone who intends to cobble their own solution at some point, knowing a project has broad support for current standards is a big plus. Thanks for the robust discussions & I look forward to watching, learning & contributing where I can.

[earlman]

this project seems to have lost steam, so i'm just here to voice my support. I ran into indiekit and webpage-micropub-to-github while researching how i'm going to re-architect my blog. both look like good options--though I'm sure this project, as a collaboration between all of you smart folks, would be a much more resilient and stable solution.

Judging by the recent commits in both projects, it seems like this topic still has a lot of interest. @grantcodes, is there anything in particular we've been hung up on here?