The relationship itself is already a subtle form of filtering. I see no reason in the spec or implementation details you can not filter on the /articles/1/relationships/tags?filter …
Let’s be clear, the example in the spec, is poor because it isn’t unique enough to really explain the difference between self and related.
"author": {
"links": {
"self": "/articles/1/relationships/author",
"related": "/articles/1/author"
},
The Author resource in this example is a sub resource of articles, which is a poor design but also confusing as an example. The following would be better.
"author": {
"links": {
"self": "/articles/1/relationships/author",
"related": "/people/1"
},
The relationship is author, it is how they are related, but the related resource object would be found at /people/1 not as a sub resource of the article itself. This isn’t bike shedding over the design, but a fundamental principle of API design. This more clearly demonstrates the difference between the relationship and the target resource of the relationship.
With these examples you can clearly see the ruby roots of the specification by its adherence to ruby-rest design which is entirely functional, but does not scale or evolve well.