capjamesgThe spec says u-logo is "a logo representing the person or organization (e.g. a face icon)" and u-photo is "a photo of the person or organization".
barnabyI don’t know of any implementations which do anything with u-logo other than perhaps using it as a fallback if there’s no u-photo, but I don’t see any reason not to use both for the same image if you consider it both a photo and a logo
barnabyit could be sensibly used in a variety of places, but that’s the only use-case for which I’m aware of actively-maintained consuming implementations
angelocapjamesg that CC license being a hinderance for adopting a small utility function is precisely the reason why i'd like indieweb-utils to be public-domain-equivalent
[tantek]capjamesg, as an h-card publisher, you can use either u-photo or u-logo if either seems to fit what you're publishing. using both shouldn't be necessary, because any consuming code that requires one should fall back to using the other
angelobut practically speaking a cassis.py port to indieweb-utils would likely be sufficiently different in structure that i believe the license would no longer apply. you could still attribute the original authors. curious what they think.
[tantek]angelo, I put the CC license on CASSIS precisely to slow down adoption while it was still "in development" to reduce the chance that bad/buggy versions spread & propagated
[tantek]are there parts of cassis.js that you want to re-use whole like the regex for auto-linking? I could wrap those in a more re-use friendly license like BSD0
barnabyafaik it’s fine to reuse code under a different license with written permission without the original author having to relicense their project. I do exactly that in taproot/indieauth, using indieweb chat logs as the record of permission https://github.com/Taproot/indieauth/blob/main/src/functions.php#L155
[KevinMarks]That regex does fell like it needs it's own repo in some ways, so you can have a multiline version that explains it and a compact on that you can include.
[tantek]if the noise of accidental auto-linking text that wasn't intended as a link is greater than the actual real world use of links to such domains, makes no sense to include it in the regex
[tantek]angelo, I believe for each new TLD I've added to the regex, for many years in the change comment, I put the use-case of the specific domain being linked to, or post linking to it, either way from an IndieWeb person as justification for adding the TLD
angeloby "test against all TLDs" i meant i'll just run the test for myself so i can see a list of the unsupported links to figure out which ones a) are being supported by your regex and b) which are not but need to be (eg. gdn)
angelo.ngo/.ong .organic .technology .house .camp .rocks .wtf; i intend to use this auto_link functionality in an editor with automatic preview so i can see solving the issue of false positives with some kind of "cancel" button that escapes the dots in the source
angeloi'm all for a default mode and then a conservative/exhaustive flag for the other approach. agree that the problem is mostly typos which should be avoided in other ways. but there's also being.able.to.write.like.this sometimes?
[tantek]quite often folks apply auto_link to *past* content, in which case retro-linking text of the past is very likely to introduce noise especially with thing like .dev .app etc.
[tantek]angelo, is ".ngo/.ong .organic .technology .house .camp .rocks .wtf" a list you personally care about or ... ? because I know auto_link has supported .rocks and .wtf for quite some time.
[tantek]if you want to really go that deep, you could offer something like the TZ database and a mode where you pass in a date and only TLDs as of that date are linked
angeloi'm going off the regex in cassis.py which has clearly become outdated. first thing i'd do is redefine that regex more explicitly so we can see which are ccTLD. then, of the remaining domains, the list can be short (based on some criteria ie. popularity) or long (based on the "full" TLD list).
[snarfed]but still needs human judgment even after TLD launch dates, because the ones [tantek] is thinking of (app dev py etc) seem to have way more false positives than true positives
[tantek]I'm against any framing of "full" or "complete" as more "correct" because the *result* is arguably *not* more correct again because of more noise than signal
[tantek]a lot of what I tried to encode into the design of auto_link is a sense of safety, that you won't "screw up" content by using it, e.g. the whole thing where it won't auto_link "twice" if you happen to run it on the same thing twice
capjamesg v0.3.1 of IndieWeb Utils is out. This release has been worked on since February: https://pypi.org/project/indieweb-utils/
[KevinMarks] Sounds good
barnaby afaik it’s fine to reuse code under a different license with written permission without the original author having to relicense their project. I do exactly that in taproot/indieauth, using indieweb chat logs as the record of permission https://github.com/Taproot/indieauth/blob/main/src/functions.php#L155
angelo capjamesg i interpreted our back and forth as MIT0 being the frontrunner https://github.com/capjamesg/indieweb-utils/issues/73 but i couldn't find any arguments in favor of one over the other..
[tantek] capjamesg, a new comment? didn't see anything in https://github.com/capjamesg/indieweb-utils/issues/73
