I will likely attend the Pre-Party for IWC NYC.
Last Updated
Map“Is it time to resurrect the DiSo Project? https://t.co/Sd3p8Gl6M8 Funny, we were here in 2006, @simonw: https://t.co/Vmz06KA1Gp /cc @willnorris @steveivy @singpolyma https://t.co/eWYliJtI2y”
People continued working on it. Everything you need using W3C standards like Webmention, Microformats2…give it a try? https://IndieWeb.org/WordPress/Plugins
Tomorrow I am going to be once again spending time in Manila. It has been on my mind lately, as it is a long journey and a hard trip. But, I intend to make the best of it and be as productive as possible.
Your Endpoint Did Not Return a Location Header
There have been some issues with Quill and other services advising that the WordPress Micropub endpoint did not return a Location header. There seems to be some confusion about this, which is partly because the message is a bit technical. One individual thought that this was related to Simple Location.
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.
Ben Werdmüller (Ben Werdmüller)I’m also going to make a strong argument in the open source Known community that syndication should be limited to webhooks going forward. In other words, third parties will be able to create microservices with a standard API, which your Known or other indieweb-compatible site will be able to connect to. You could click a button to notify those services (or have your site do it automatically). But any kind of API maintenance would be taken out of the core code or official plugins. Not only is life too short, but it’s long past time to stop building code on top of centralized silos of content.
I have to agree with Ben. The Micropub plugin for WordPress triggers a WordPress hook based on syndication targets and I’m working on a compatible system for the Post Editor, so that the UI doesn’t need to know how the item is POSSEd.
This is because I also don’t want to deal with silo interfaces most of the time.
Nothing like a Catskills show.
A excitement packed Saturday night.
Aaron Parecki (Aaron Parecki)OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.
While OAuth is a great framework for this, the way it has ended up being used is …
IndieAuth, the extension to OAuth 2.0, was developed by Aaron Parecki and implemented by multiple people in the IndieWeb community, including myself.
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.
Brainstorming on Implementing Vouch, Following and Blogrolls
Vouch is an extension to the webmention protocol. Webmentions usually have two parameters…source and target. Target is the URL on your website that the Source URL is linking to.
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.
Portland Union Station
Somewhere 35000 feet over Montana on JetBlue flight 236 to Seattle.
Hi there, can you tell me please if Webmention collects any personal data on my blog? Maybe you heard of the GDPR in Europe, we have to declare if someone collects personal data… Thanks for your help!
I am very well aware of it, as a contributor, though I don’t live in the EU. And the author/creator of the plugin lives in the EU. The latest version adds some information on this into the plugin to try and make it clearer, but we continue to try to improve. Will try to clarify…This is a bit of a long explanation, but I feel that others may ask this question and want to try to help with the answer.
Disclaimer: Some of this is my interpretation and opinion. Anything technical is a fact as I understand it.
A webmention consists of two properties. A source URL and a target URL. So, when I link to a page on another site, a webmention is sent to that page if it supports it, telling it that I linked to it. The webmention plugin on the target side then generates and displays a link showing that site name(which it extracts from the title of the page) linked to that posts. Even under GDPR, linking to another site is not a personal data violation. Therefore, that is fine.
Now, there is a debate as to whether storing the IP address of the webmention is storing data. Webmention doesn’t actually need to do it…but WordPress does it for new comments by default. WordPress itself is looking into anonymizing that data to avoid the issue, and even though I myself don’t agree with that interpretation of the GDPR for personal use, as it doesn’t add anything to the presentation, I was going to, when the new functions are added, ensure they are applied to webmentions, which is a type of comment.
If you are concerned about data collection, the second plugin, Semantic Linkbacks, which is separate, is not required. But, I think the experience of Semantic Linkbacks is worth installing. Semantic Linkbacks reads the URL of the page that sends you the webmention for more information.
So that means it goes and looks at your page for your site name and author name, and instead of the generic page title, it tries to format your webmention as a better comment. It finds the name of the author of the page, the site name, title, etc.
But, webmentions require affirmative action. You have to link to me. Someone has to send one. If you didn’t want that outcome, why install the plugin that has this feature? So, if you have a privacy policy, you probably should outline that you receive webmentions and what you do with them…namely, display them.
So, the data that Semantic Linkbacks extracts does include information if your site is marked up to support it. So, if your author image is marked up as such, it will note this so it can display it. The image on your site is one you yourself chose to represent you. Same with the other information. It is basically trying to represent the link you made to the site accurately.
Any site that receives webmentions should respect any request to remove their display or purge the information. But webmention itself allows for this. If you send another webmention, it will update. So, if you take down the page, send another webmention and it will purge the comment. There’s even a form built into the Webmention plugin for that.
Under GDPR t0 my understanding, you have a right to see what data a site has on you and get a copy of it…we have that covered because the data is a copy of the page you yourself created. You have the right to correct incorrect data…there’s the update webmention functionality.
And if we didn’t, WordPress is building in tools for data export, deletion, and anomymization…regrettably though, they use email address as a way to extract comment and user data…something the plugin doesn’t collect.
I won’t speak for Matthias Pfefferle, who authored the plugin and has been kind enough to put up with my submissions to it, but he’s given me the impression that he takes this very seriously. And even though I don’t agree with the way people seem to be applying GDPR concerns to this, I respect their concerns enough to try to address them through plugin enhancements that will allow better controls over this.
As another side note, the WordPress Core team, who is scrambling to add GDPR tools to WordPress itself, didn’t consider Pingbacks and Trackbacks, built into WordPress, to be something to address as a GDPR concern to my knowledge. Webmention functions the same way as those two in terms of what it does, although it is a newer specification.
Watching the Google I/O Keynote. They are saying Hey, Google a lot. Had to mute my Google Home.
Privacy
I admit to a certain amount of frustration on the subject of privacy lately. It seems, in all aspects of my life, both personal and professional, the new data privacy regulations that the EU rolls out May 25th are a theme in every discussion.
I don’t live in the EU, and I know that the European view on privacy is very different than the American one. Anything I say below is my opinion.
I am also an archivist and librarian by education, if not by profession. We learn about the past by reading the materials of the day. The fact that email is so easy to keep and delete makes things difficult for us to archive for the future. Does the right to privacy mean we lose the ability to look back, because we don’t want to remember?
Historical concerns aside, let’s think about today. In the majority of states in the US, only one party partipating in a phone call is required to record a conversation and even post it. Privacy is very lopsided. There is no such thing as absolute privacy.
For me, keeping a copy of communications I was a party to is perfectly acceptable. My website is where I keep my copy. It is not covered by privacy regulations. I have no business agenda there. I will not sell your data or use it for anything else but archiving that conversation.
The thorny issue is whether or not I have the right to display that information publicly. This is because I am, in some cases, copying that data from another service. For example, Twitter or Facebook. Those services got permission to store that information and you have the right to manage it. But you may not know that I have copied it to ask me to remove the public display of your image.
But how is that different than someone creating a screenshot of the post? Which was public information at the time?
As a private individual, I think it is mandatory that I post a policy about what I do. And that I will hide or remove information on request. As a developer of Indieweb tools, I think I should give people the option to not store information if they so choose.
So, I am going to build the tools for people to not collect data. I am going to stop what I am working on and do some of this right now. But I still will. I am going to try to better secure that data. I am going to be clearer about it. That is the lesson I can take away from this and should. That we need to think about privacy impact.
I hope those who are more concerned about this tell me through my site they don’t want me to share our public conversations that they were happy to put in a public forum. I will then restrict them to my eyes only.
In Indieweb terms, I support webmention deletion. If the original source changes and you send a webmention, my site should remove or update my copy.
Disclosure: Your responses to this may be captured for archival purposes. Please advise me if there is an issue.
Originally intended to showcase a privacy-centred implementation of emerging social web technologies – with the aim to present a solution not initially motivated by legal requirements, but as an example of privacy-aware interaction design – my “social backfeed” design process unveiled intricate challenges for Indieweb sites, both for privacy in general and legal compliance in […]
I have been thinking about this issue a lot. GDPR seems to be everywhere, and I’m not sure that storing information on interactions is a privacy issue, but I want to respect people’s concerns. GDPR or not, I do not think this is a use case the law intended to prevent.
You use the WordPress suite of plugins. And being as I’m as regular contributor, there are a few ideas I’ve floating that I think are a good start, and invite you to contribute more.
- Add text to the Webmention form that explains how to use it to delete a mention. Since the form can be used without supporting webmentions on your own site, this is something that should be made clear.
- Add Setting to not display avatar/photo
- Add ability to edit mentions, to correct inaccurate data.
- Add setting to store more/less data.
- Add privacy policy to plugin for those who install it and add text/link to webmention form.
- Explain how to request a takedown of information.
- Periodically poll/refresh sources.
- Allow a different level of processing for ‘native’ webmentions vs backfeed run through a service like Bridgy.
This doesn’t solve all of the problems necessarily, but I think these ideas are a good faith effort in that direction.