Skip to content
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

References for "fast-follow" technique #633

Open
fulldecent opened this issue Apr 17, 2024 · 9 comments
Open

References for "fast-follow" technique #633

fulldecent opened this issue Apr 17, 2024 · 9 comments

Comments

@fulldecent
Copy link

In https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid-enabled-fast-follow-share-links a technique is specified for embedding a URN (the GUID) inside a URL, such that the URN can be recognized and extracted across applications.

Is this technique referenced from anywhere else or is this original research? I'd like to document the reference if it is available.

@jamescridland
Copy link
Contributor

It's an original idea, I was one of the authors.

I don't believe it is currently implemented by anyone, and I do wonder if it's worth removing from the spec as a result.

@keunes
Copy link

keunes commented Apr 19, 2024

I still love the idea and would find it cool to see it implemented in AntennaPod one day.

@theDanielJLewis
Copy link

I, too, still love the idea and would like to see it also support an episode GUID so you could tap a link in episode notes within your podcast app and it would take you directly to another episode of another podcast.

@fulldecent
Copy link
Author

I also saw this technique implemented in this publication:

GS1 Digital Link Standard: URI Syntax (part of GS1 Digital Link)

It is a very important standard coming into effect for all consumer packaged good. Basically everything you buy will have that.

See section 61.

@jamescridland
Copy link
Contributor

I also saw this technique implemented in this publication:
GS1 Digital Link Standard: URI Syntax (part of GS1 Digital Link)

Thank you, that was an interesting read. The way that this has been constructed to use any domain, but to be coded in such a way that a GS1-aware app can extract additional data, is very similar. Interestingly, they've used query attributes rather than a fragment identifier approach (the bit after the #).

Using a fragment identifier means that webservers will never see the fragment; just a JavaScript-enabled browser. This may be a wrong approach: GS1's approach, using query attributes, mean that webservers can also see the additional data being transmitted and may be able to use that in some way. However, we can't guarantee that every website will deal with a ?_fastfollow=(x) attribute, and it might mess up pagerank and analytics.

@fulldecent
Copy link
Author

You're welcome. Yes, I think the fragment approach is right for the requirements here. GS1 specifies a is-a relationship and here we are specifying a is-kind-of relationship. Fragments seems more semantic.

@theDanielJLewis
Copy link

Queries in a URL also usually bypass webserver caching.

@jamescridland
Copy link
Contributor

Queries in a URL also usually bypass webserver caching.

Not always the case; that's up to the website cache. As one example, https://podnews.net/podcast/i6ay and https://podnews.net/podcast/i6ay?status=iamabanana will always grab the same cached copy. (But, that's not the case in https://podnews.net/classifieds where the cache performs very differently).

@theDanielJLewis
Copy link

Not always the case …

Thus why I said, "usually." It's even referred to as "cache-busting" to add a random URL parameter. (I usually go for ?blah=1.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants