Year: 2018
MapBrainstorming on Implementing Vouch, Following and Blogrolls
The vouch parameter is a third URL to help the target determine whether or not they should accept the webmention. This should block automated spam and aid in moderation.
Several people have implemented receiving vouches. It is relatively easy to look at a vouch URL and see if it links to a third-party who you have approved of in the past. While there are more advanced things you can do, that is the basic summary of the protocol.
The harder part, and less implemented by others is sending of vouches. Where do you find people who have been approved by people you have approved of? It would really help if we had some more discussion on this.
So, at the Indieweb Summit, we talked about this a bit, after which I implemented a primitive Vouch receiver. My solution was to use a manually curated domain whitelist that I’d previously built as my source for acceptable domains.
There are some suggestions on where to get this list. Several people generate a list from referrers. This sent me down the road of looking as to whether I’d want to implement refbacks to add more mentions to my website…except there is a lot of noise. Refbacks are basically the same as webmentions, except the source is gleaned from the referrer header that sites send when a page is accessed.
Even if I have a list of sites that I approve of, I would have to crawl them to find links from them to other sites. So, I think we should all help each other out on this.
That means we need to post our list of approved domains somewhere on our site. That used to be quite popular. It was called a Blogroll. It was sites you read, followed, or recommended. There are other terms for it. But, this is a perfect place to get a nice list, and if we publish them, then we can help the Vouch cause.
But the problem is, how do you tell a Vouch receiver where your list is. There are some brainstorming items about blogrolls and following/follower lists
- Follower lists marked up with rel=”follower” or rel=”following”
- Contact lists marked up with rel=”contact”
- Follow Posts marked up with u-follow-of
Follow posts would create an h-feed of follow posts that could be used to generate a list. You can have a specific page on your website, but there isn’t a way to indicate this to someone looking for it.
There is rel-directory, which is the reverse direction. It indicates that the link is to a directory in which the current page is listed. What we seem to be missing is a property that says that a page is a feed of followers that can be placed inside an h-card or on a home page.
u-follow-of is a proposed property that indicates that an h-entry is considered a follow post, which is a post indicating you have followed someone, then a feed of follow posts could be parsed and read by a reader. If you add in the XFN relationships to that, you can build even more detail.
The reverse relationship would, in theory, be u-follow, which would be a URL to the follow post of the current URL(the thing being followed).
Feeds are identicated by rel=”feed” to link from your homepage to those feeds. But there is a lack of indicating what type of feed it is, such as rel=”blogroll” or rel=”following”. I’m not sure, and need more discussion about what to use for this.
But, this has the ability to solve a lot of problems. Imagine I…
- Post Follow posts when I follow someone
- Use this to generate a blogroll/followers list
- Send webmentions when I follow someone so they can build relationships
- Use that list as a vouch list. Use other people’s blogrolls/followers lists as a means to generate vouch lists…which reduces the implementation cost of Vouch.
Needs work, but suddenly I want to do Follow posts.
The problem has been that people conflated it with the service Aaron created as a reference implementation, which implemented IndieAuth for people who didn’t have it by using the OAuth services of sites like Twitter and Github to bootstrap the service.
Aaron succeeds here in finally conveying a point it took me a long time to understand, and partially only by reading and implementing one of these.
Was pleased to see the founder of Home Assistant, a product I use, tweeting that he would adopt this in that product. Looking forward to seeing what people come up with.
This is because I also don’t want to deal with silo interfaces most of the time.
Your Endpoint Did Not Return a Location Header
This indicates an error on the part of the Micropub plugin. Regrettably, in addition to not displaying the error response prominently, the Micropub specification dictates that the error response returns one of 4 error codes, and may return a human readable error description to assist the client developer in understanding the error, but is not meant to be shown to the end user.
This does not account for errors on the endpoint side that may need to be debugged. Currently, the WordPress plugin that creates the endpoint does not surface error messages on its side either to allow you to figure this out.
Better error messaging to the end-user on one side or the other seems to be a common issue amongst Indieweb tools to help them figure out the issue.
The most common issue that explains the failure is an inability to associate the URL with the user account. There are two versions of the software that does this.
- In the IndieAuth plugin, to ensure accuracy, the plugin passes the WordPress user ID in the return to ensure that it can find it.
- If you don’t have the IndieAuth plugin installed, the Micropub plugin uses an external IndieAuth endpoint instead of a built-in one, and the following techniques to find the WordPress user from your URL
- If you have the Indieweb plugin installed, it looks in its settings for the default author on a single author site.
- If you are using the URL of your author post archive, usually /author/username it will try to use that to get your username and therefore your user ID
- If you have set a website URL in your profile, it will try to use that. Please make sure your website URL uses https if your website does, as this has caused some issues in matching.
In both plugins, we continue to improve the functionality in this case and I often port ideas that improved functionality in one version into the other, as they are both authorize Micropub using IndieAuth, but in the case of the Indieauth plugin, it also implements the IndieAuth functionality.
Right now, I’m working on improvements to the Micropub plugin to improve the error handling, among other things, and hopefully this will help.