New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

publish: support fragment for identifying individual entry #445

Open
csarven opened this Issue Aug 16, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@csarven

csarven commented Aug 16, 2015

http://csarven.ca/webmention#i-20150810110710 is an in-reply-to to https://twitter.com/coreymwamba/status/630417520550375424 . It also contains p-name, e-content. When I try to publish/preview this on bridgy by entering post URL: http://csarven.ca/webmention#i-20150810110710 (w/ "include link" checked), I get:

Webmention (csarven.ca/webmention#i-2...)

The documentation https://www.brid.gy/about#microformats states:

In general, Bridgy prefers to use p-summary if available, then the full e-content, and finally p-name, in that order. The one exception is original tweets (not @-replies) on Twitter: for those, it prefers p-name before e-content. Background discussion.

My expectation was a reply with a preview text along the lines of:

@coreymwamba I use schema.org, FOAF SIOC, Open Annotation, and Activity Streams, where applicable. http://csarven.ca/webmention#i-20150810110710

See also: http://pin13.net/mf2/?url=http%3A%2F%2Fcsarven.ca%2Fwebmention

I've tested by adding the following at the top of http://csarven.ca/webmention (within h-entry, e.g., preceding h1 class="p-name"):

<a class="u-in-reply-to" href="https://twitter.com/coreymwamba/status/630417520550375424">foo</a>

Previewed both post URL's http://csarven.ca/webmention and http://csarven.ca/webmention#i-20150810110710 and got this:

@coreymwamba This is my site’s webmention endpoint. Send POST requests to this URL (csarven.ca/webmention)… (twitter.com/coreymwamba/st...)

Which looks like an expected output. At least for http://csarven.ca/webmention .

Based on what I'm observing (i.e., I didn't look at bridgy's code), I think what's happening is that URIs (h-entrys) with fragments are ignored or at least nested h-entries are not being picked up.

I also suspect this issue is related to webmention.io's way of handling threaded interactions (with fragments?). See aaronpk/webmention.io#52

Happy to test further. Let me know if I've overlooked something.

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Aug 16, 2015

Owner

interesting idea! you're right, we only support publishing pages with a single h-entry right now, and we ignore any fragment in the source URL.

we discussed concerns with publishing feed (multi-entry) pages in #332. if we expect a fragment, though, and only look at that entry, it might work.

thanks for the idea! this could definitely be a reasonable starter project if you're interested in diving into the code. same with #444. :P

Owner

snarfed commented Aug 16, 2015

interesting idea! you're right, we only support publishing pages with a single h-entry right now, and we ignore any fragment in the source URL.

we discussed concerns with publishing feed (multi-entry) pages in #332. if we expect a fragment, though, and only look at that entry, it might work.

thanks for the idea! this could definitely be a reasonable starter project if you're interested in diving into the code. same with #444. :P

@snarfed snarfed changed the title from Discovering and previewing threaded interactions with in-reply-to to publish to Twitter to publish: support fragment for identifying individual entry Aug 18, 2015

@snarfed snarfed added the publish label Aug 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment