Open voxpelli opened 5 years ago
Excellent idea! I'm all for it!
I don't know if you've mentioned them already but I've talked with @EdwardHinkle and @martymcguire about a similar idea of having express middleware to do generic things.
I'm also the proud owner of the @indieweb organization on mom if we ever get to a stage where we have something were happy to publish as a group.
As for relation to my current personal projects, I have a few endpoints I have made - mainly a micropub endpoint, webmention endpoint and token endpoint. The majority of the code it fairly resuable but not 100% designed as npm modules. The goal for my project is to be a fairly feature complete, fully extendable indieweb backend with the frontend totally independent. I would love if it was usable with static sites but that is not my main goal.
In my indieweb dreams I would love to have a bunch of reusable endpoints / modules to cover a range on indieweb functionality. Mainly from the top of my head:
That's about all I can think of for now on my phone but I'm sure there is much more
Forgot media endpoint
So I've done a quick look into the various js based micropub endpoints and here is what I have found them to support based on micropub.rocks tests. (note this absolutely may be missing projects or features of each project)
Test Number | Test Name | grantcodes/micropub-endpoint | voxpelli/node-micropub-express | paulrobertlloyd/indiekit | muan/micropub-endpoint |
---|---|---|---|---|---|
100 | Create an h-entry post (form-encoded) | ✔ | ✔ | ✔ | ✔ |
101 | Create an h-entry post with multiple categories (form-encoded) | ✔ | ✔ | ✔ | ✔ |
104 | Create an h-entry with a photo referenced by URL (form-encoded) | ✔ | ✔ | ❌ | ✔ |
107 | Create an h-entry post with one category (form-encoded) | ✔ | ✔ | ✔ | ✔ |
200 | Create an h-entry post (JSON) | ✔ | ✔ | ✔ | ❌ |
201 | Create an h-entry post with multiple categories (JSON) | ✔ | ✔ | ✔ | ❌ |
202 | Create an h-entry with HTML content (JSON) | ✔ | ✔ | ✔ | ❌ |
203 | Create an h-entry with a photo referenced by URL (JSON) | ✔ | ✔ | ✔ | ❌ |
204 | Create an h-entry post with a nested object (JSON) | ✔ | ✔ | ✔ | ❌ |
205 | Create an h-entry post with a photo with alt text (JSON) | ✔ | ✔ | ✔ | ❌ |
206 | Create an h-entry with multiple photos referenced by URL (JSON) | ✔ | ✔ | ✔ | ❌ |
300 | Create an h-entry with a photo (multipart) | ✔ | ✔ | ❌ | ✔ |
301 | Create an h-entry with two photos (multipart) | ✔ | ✔ | ❌ | ✔ |
400 | Replace a property | ✔ | ❌ | ❌ | ✔ |
401 | Add a value to an existing property | ✔ | ❌ | ❌ | ❌ |
402 | Add a value to a non-existent property | ✔ | ❌ | ❌ | ❌ |
403 | Remove a value from a property | ✔ | ❌ | ❌ | ❌ |
404 | Remove a property | ✔ | ❌ | ❌ | ❌ |
405 | Reject the request if operation is not an array | ✔ | ❌ | ❌ | ✔ |
500 | Delete a post (form-encoded) | ✔ | ❌ | ✔ | ✔ |
501 | Delete a post (JSON) | ✔ | ❌ | ✔ | ✔ |
502 | Undelete a post (form-encoded) | ✔ | ❌ | ❌ | ❌ |
503 | Undelete a post (JSON) | ✔ | ❌ | ❌ | ❌ |
600 | Configuration Query | ✔ | ❓ | ✔ | ✔ |
601 | Syndication Endpoint Query | ✔ | ❓ | ✔ | ❌ |
602 | Source Query (All Properties) | ✔ | ❓ | ✔ | ❌ |
603 | Source Query (Specific Properties) | ✔ | ❓ | ✔ | ❌ |
700 | Upload a jpg to the Media Endpoint | ✔ | ❌ | ✔ | ✔ |
701 | Upload a png to the Media Endpoint | ✔ | ❌ | ✔ | ✔ |
702 | Upload a gif to the Media Endpoint | ✔ | ❌ | ✔ | ✔ |
800 | Accept access token in HTTP header | ✔ | ✔ | ✔ | ✔ |
801 | Accept access token in POST body | ✔ | ✔ | ✔ | ✔ |
802 | Does not store access token property | ✔ | ✔ | ✔ | ✔ |
803 | Rejects unauthenticated requests | ✔ | ✔ | ✔ | ✔ |
804 | Rejects unauthorized access tokens | ✔ | ✔ | ✔ | ✔ |
Other projects I looked at:
I think this is a great effort. Mine (abode) is currently using voxpelli/Node-Micropub-express as grant mentioned. I have been planning on building one from scratch so this effort would definitely help on preventing me from re-inventing the wheel. A couple important aspects in my mind:
the output of the Middleware Library shouldn’t try to do anything fancy. It should output standard MF2 JSON and then individual libraries that use the Micropub Endpoint base can convert the mf2 JSON to whatever is needed.
support for Update and Delete are definitely essential for me.
Some other thoughts:
Ultimately though, I think it would be amazing if we were able to all contribute to Node.js libraries in npm that allowed for customizable/extensionable integration into other apps.
Also I don’t know how much of you all use TypeScript but adding TypeScript support to them as well would be pretty great.
I agree with @EdwardHinkle
The endpoint should definitely just pass through mf2 json, and should at least be able to handle all of those tests from micropub.rocks I listed above.
Another couple of notes on what a shared endpoint could potentially handle:
The only thing I am not sure I agree with is TypeScript, I think TypeScript is great but if it is a community project it is just one extra thing that someone would have to learn before being able to contribute.
Another thing I'd like to see decided prior to starting any development would be about the actual method of using the library.
For now voxpelli/node-micropub-express uses a object to configure the endpoint:
const micropub = require('micropub-express');
app.use('/micropub', micropub({
tokenReference: {
me: 'http://example.com/',
endpoint: 'https://tokens.indieauth.com/token',
},
handler: async (micropubDocument, req) => ({ url: 'http://example.com/url/to/new/post' })
}));
But the other options is to use methods, more like how express actually works:
const Micropub = require('micropub-express');
const micropub = Micropub();
micropub.handler(async (micropubDocument, req) => ({ url: 'http://example.com/url/to/new/post' });
micropub.setTokenReference({
me: 'http://example.com/',
endpoint: 'https://tokens.indieauth.com/token',
});
app.use('/micropub', micropub.router);
Note: just examples, not suggesting any sort of vocabulary.
Personally I think I prefer using the methods, but I am not 100% sure of the pros and cons
I think I opted for using an object to configure as then it’s easier to validate early on that all necessary config has been given, but I’m neither very opinionated about it
tors 28 feb. 2019 kl. 13:31 skrev Grant Richmond notifications@github.com:
Another thing I'd like to see decided prior to starting any development would be about the actual method of using the library.
For now voxpelli/node-micropub-express uses a object to configure the endpoint:
const micropub = require('micropub-express'); app.use('/micropub', micropub({ tokenReference: { me: 'http://example.com/', endpoint: 'https://tokens.indieauth.com/token', }, handler: async (micropubDocument, req) => ({ url: 'http://example.com/url/to/new/post' }) }));
But the other options is to use methods, more like how express actually works:
const Micropub = require('micropub-express');const micropub = Micropub(); micropub.handler((micropubDocument, req) => ({ url: 'http://example.com/url/to/new/post' }); micropub.setTokenReference({ me: 'http://example.com/', endpoint: 'https://tokens.indieauth.com/token', }); app.use('/micropub', micropub.router);
Note: just examples, not suggesting any sort of vocabulary.
Personally I think I prefer using the methods, but I am not 100% sure of the pros and cons
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/voxpelli/webpage-micropub-to-github/issues/97#issuecomment-468255555, or mute the thread https://github.com/notifications/unsubscribe-auth/AACGmWW0kYdbEd1-pqrS_KqVOTrBTksRks5vR8wMgaJpZM4bKIdy .
happy summer friends. Wondering if there's been further discussion on this and https://github.com/paulrobertlloyd/indiekit/issues/1#issue-413400782
I'm eerily close to moving back to Jekyll and assessing the landscape. I'm a big fan of everyone's work.
@miklb I don't think there's been much extra discussion elsewhere yet. But I'd be keen to get started on something soon. Particularly on micropub, token and auth endpoints.
I think there are already at least a couple of express token endpoints out there that are pretty much done.
For micropub the projects mentioned above are all good, but handle things differently, but a new higher level module could probably be put together using some of the best parts from each.
As for auth, I don't think there is much built so far that would be easily reusable.
But I am not really sure what would be a best starting point. Maybe a new repo with a project that lays out a bit of a road map?
I went ahead and made a new repo specifically for micropub endpoint planning: https://github.com/grantcodes/future-micropub-endpoint
@miklb You asked this question at just the right time; I had not been working on IndieKit since March, but started looking at it again this month, so it’s very much front of mind.
I’m excited by the moves @grantcodes has made to elicit collaboration among different project authors, and will start responding with my thoughts and contributions at the above repo.
@paulrobertlloyd I've been lurking watching your repo so can't claim serendipity :-)
I'm excited too and am a willing guinea pig for my new site. Certainly will try to chip in where I can code wise or other types of contribution.
This is a tracking issue for collaboration work in my part of the Node.js IndieWeb ecosystem.
Issues in other repos
My Micropub-related modules
micropubDocument
.micropubDocument
as its input, and converts this data into a standard that can be published elsewhere. Currently supports the Jekyll format.format-microformat
can be published to a Jekyll blog hosted on a GitHub, or a GitHub Pages site.Other IndieWeb projects of mine
Collaboration opportunities found so far