ancardaUbuntu 17.10. This happened the other day too, although a reboot fixed it. In the process of trying to debug what was going on, I disabled IPv4 in Network Manager and that only took affect this morning when I booted up. Took some time to figure out it was just me being an idiot
ancardaI'm not sure why it broke the other day though - but now it's not exclusively using IPv4 DNS servers so it can reach Gmail without any IPv4 support now, which is nice
vanderven.se martijnedited /authorship (+970) "/* Other theoretical */ When mapping h-entry with h-cards elsewhere in the DOM, it makes sense to do so before grabbing external resources. Discussion prompted by keithjgrant" (view diff)
vanderven.se martijnedited /Micropub-brainstorming (+1146) "/* Micropub for Multi-user Sites */ Thinking about this. Micropub dictates a token-endpoint-per-micropub-endpoint instead of the assumed token-endpoint-per-user-identity." (view diff)
ZegnatMy 2018-01-01 idea is to do all posting to my blog over Micropub, and because I will be logging in using vanderven.se/martijn/ I have been reviewing some of the micropub & identity decoupling discussions
Loqi2018-01-01-commitments are implementation and launch commitments publicly made by the IndieWeb community to ship on their personal sites by 2018-01-01 00:00 local time https://indieweb.org/2018-01-01-commitments
sknebelZegnat: yeah, it kind of feels like you'd have to have "profiles" in the community blog and you log in as that profile (which then could do authentication by in turn running indieauth against your main identity), not as the main user
Zegnataaronpk, yeah I guess that works. It just seems weird to me that we then need a double IndieAuth protocol dance. I also as a user then need to go through the communal blog to revoke a token rather than being able to do it myself.
sknebelI guess you could have the micropub endpoint go look up your token endpoint and use that to verify the token, as long as it whitelists the allowed identities
aaronpkmicropub requests happen out of the blue, with no advance notice. I don't want to a) be reliant on hitting an external API to validate every request, and b) I want to be able to revoke tokens I issue
ZegnatOh I get that less external calls are good for implementors, aaronpk. I'm only saying that (unless you police when logins are allowed) fear for the token endpoint being compromised is not a reason as the same applies to authorization endpoints.
Loqifollow is a common feature (and often UI button) in silo UIs (like Twitter) that adds updates from that profile (typically a person) to the stream shown in an integrated reader, and sometimes creates a follow post either in the follower's stream ("… followed …" or "… is following …") thus visible to their followers, and/or in the notifications of the user being followed ("… followed you") https://indieweb.org/subscribe
aaronpkright now I prioritize uid, then use url if uid is not present, and if neither is present, I hash the content and use that. that's what I use as the unique identifier internally in order to know whether to update an old post or add a new post
aaronpkhere's an example: say the microsub client wants to hide/block a specific post, it needs a way to refer to that post when talking to the microsub server
aaronpkin general, if there is a uid, it should be prioritized over url. there are lots of examples of feeds where the URL scheme changes but the uids stay the same. e.g. wordpress uses example.com/?id=400 as a uid but then you can change the URL scheme to /yyyy/mm/slug etc
LoqiA GUID or Globally Unique Identifier is a (typically) 128-bit number to uniquely reference or identify something; on the IndieWeb, GUIDs are encouraged in some feed file formats as supposedly more persistent than permalinks but in practice GUIDs have been less portable and harder to preserve/migrate/restore than permalinks https://indieweb.org/GUID
tantekI think it's that permanence/uniqueness of UID/GUID for posts is one of those aspirational things in feed specs, more than actually useful as intended
aaronpksay i'm following example.com and it reports a post with a url like example.org/post/100. For the purposes of storing and deduplicating that, it's fine for me to use that URL within the scope of the example.com feed. However, when I report that to the client, it's no longer within the scope of example.com so there's a security risk that the client may allow that post to be overwritten by some other
tantekI think only example.org can canonically claim to provide a url like example.org/post/100. if you want to enable example.com to provide an example.org/whatever post, then you start down the path of signatures
aaronpkthe obvious question being what should a consumer do that encounters a post with a URL from a domain different from where the content came from?
tantekI believe that's the reasoning for using signatures in federation, so that a post can be passed along any number of servers (fatping) without necessarily having to contact the original domain
aaronpkyeah signatures and a key management scheme solve that use case. it's more immediately applicable in the indieweb context for things like in-reply-to and repost-of where the site may be showing expanded content from another domain already
aaronpkso I need to code this into my feed processing function. if I encounter a URL property from a different domain, I should straight out reject the post?
aaronpkso, it will get a websub payload with the contents of a feed (h-entry or Atom/RSS or JSON Feed), and will process each item in the list. if that item has a URL that's on a different domain, it's going to need to bump that into the queue to fetch it from the remote URL
aaronpk[cleverdevil]: btw these XRay URLs are the format that i'm expecting microsub clients to interact with, so I hope it looks relatively easy to consume
aaronpkfrom https://jsonfeed.org/mappingrssandatom "link with rel="alternate" maps to url in JSON. If rel="related" is used for links to an external site, in JSON Feed those map to external_url."
aaronpklooking at the daringfireball posts, most of those have original content that he wrote, and usually contain a blockquote from the site. that looks an awful lot like my own bookmark posts
[kevinmarks]That's fair. The question is how much of this messiness you want to model, and how much you're happy with pruning off to fit into your model
aaronpkso if I follow https://news.indieweb.org/en in my reader, it should avoid using the content of the h-entrys it gets in the websub notifications, and instead go fetch the individual URLs
aaronpkso, that solves part of the problem. the remaining issue is how should I handle uniquely identifying posts. right now h-entry lists both uid and url properties.
aaronpkso since the goal of microsub is to simplify consuming content when building a reader interface, I want to avoid clients having to do that logic of "use uid if present otherwise use url" etc, especially since some clients might not end up implementing that and we wouldn't know
aaronpkso that begs the question of whether the microsub server should be generating its own IDs for the client to use when deduping items and referring to items at the server
aaronpkI'm kind of leaning towards just saying that the server should include its own "id" property, and that can be any string value such as the URL of the post or an internal database ID
aaronpkany other interactions the client would do with the post would be doing things like replying to it, or liking it, which it does at the micro*pub* endpoint and uses the post's URL
aaronpkif i'm doing the thing where I prioritize the uid if present and use url only if there is no uid, that means I have to tell clients how to refer to posts by either of those properties
aaronpkthe only trick is I don't think I want to make up a URL if there isn't actually one in the item, because I don't want to be in a situation where clients are hesitant to use the value for fear of accidentally misleading users to click on a thing that doesn't exist
aaronpkIMO the easiest thing that would probably have the least consequence if ignored would be to prepend a "#" to an arbitrary string, so clients could check "does the URL begin with '#'? if so, don't show the URL", and if they forget to add that check, clicking that in a browser will not navigate away to some unexpected place
aaronpkbut yeah the two different properties idea was what I was saying earlier where the microsub server could just always use its own local ID for the client to refer to posts
aaronpkI guess if the microsub server makes up a URL for a post that exists on its domain and actually displays the post at that URL, then that seems like a pretty good fallback behavior
aaronparecki.com deleted /events/2017-12-06-homebrew-website-club "deleting because it was the off-week for PDX and PDX is cancelled"
loqi.me edited /Indieweb_for_Journalism (+123) "KartikPrabhu added "https://www.poynter.org/news/after-watching-gothamist-and-dnainfo-disappear-journalist-built-tool-help-others-save-their" to "See Also"" (view diff)
petermolnar you mean you only have an ipv6 address?
vanderven.se martijn edited /authorship (+970) "/* Other theoretical */ When mapping h-entry with h-cards elsewhere in the DOM, it makes sense to do so before grabbing external resources. Discussion prompted by keithjgrant" (view diff)
Loqi 2018-01-01-commitments are implementation and launch commitments publicly made by the IndieWeb community to ship on their personal sites by 2018-01-01 00:00 local time https://indieweb.org/2018-01-01-commitments
jkphl.is uploaded /File:hwcnue-2017-11-22.jpg "Homebrew Website Club Nürnberg 2017-11-22 https://indieweb.org/File:hwcnue-2017-11-22.jpg"
tantek points to /jf2#IndieWeb_Examples
aaronpk e.g. all the feed reader apps on https://indieweb.org/feed_reader
[cleverdevil] I like to see this activity on the microsub spec ?
[kevinmarks] Can you use a hash url, then everything is still a url
KartikPrabhu rel=related lol!