tantekGWG - problem right now with building a real time search engine is that no one would bother using it unless it had Twitter firehose indexed, which is prohibitive (both from a pay-Twitter perspective, and from a build-infrastructure-to-handle perspective)
snarfedkylewm GWG: if you guys come up with a better bridgy publish algorithm for figuring out what to publish based on p-name/p-summary/e-content etc, please do file an issue, i'll happily implement it
kylewmGWG: even without an algorithm, I would like a GH issue to track example posts, what you wanted Bridgy publish to do and what it did (assuming that's ok with snarfed)
tantek.comedited /Twitter (+922) "break down search & notification features into specifics in terms of indieweb features, move client support to a new section" (view diff)
mkoIt has almost every piece of relevant information that you could want plus all of the potential places that I post, could be contacted, or otherwise reached.
tanteksnarfed - for your review, in particular the expanded treatment of search and notification in terms of a bit more detail / description of indieweb equivalents
mkoI'd love to have that on its own page with better formatting and features around it, but there's no way to expose it to a parser without changing all of my rel=me links on social services to point to the about page of my website instead of my homepag.e
tantek!tell snarfed for your review, in particular the expanded treatment of search and notification in terms of a bit more detail / description of indieweb equivalents. many of those details are a first attempt - feel free to disagree/dispute/improve http://indiewebcamp.com/Twitter#Features
Loqisnarfed: tantek left you a message 10 minutes ago: for your review, in particular the expanded treatment of search and notification in terms of a bit more detail / description of indieweb equivalents. many of those details are a first attempt - feel free to disagree/dispute/improve http://indiewebcamp.com/Twitter#Features
snarfedtantek: notification part lgtm. search part is a good description of what we'd need to replace twitter on our own site(s), but it's not really a description of twitter's own search, which it probably should be given the section heading
tantekGWG, kylewm, mko - yes u-url for all your profile URLs is sensible. In terms of which matters more, you can always order them (order is preserved when parsing), and use rel=me on them and also use u-uid to what you consider your canonical / unique URL for you.
Loqisnarfed: tantek left you a message 14 minutes ago: yes we probably need to at least document the question of what would it take to stop using twitter.com for search
tanteksnarfed - thanks for catching that - I was trying to keep too many things in my head and the right thing ended up in the wrong place - take a look now: http://indiewebcamp.com/Twitter#Features
tanteksnarfed++ for so politely saying I think you got the search description wrong in the Twitter features description. Good example to learn from. :)
gRegor`My webmention plugin was pretty tightly tied to the blog posts, so I've been working on abstracting it so I can display comments on any URL path, not just an article.
wolftune, sparverius, fmarier and GWG joined the channel
cuibonobojust for some perspective: my primary motivation for moving to indieweb is actually because of these more fragile sites: bookmarks, wishlists, pinboards, etc.
cuibonoboi gotcha. i'm looking to build something that allows my stuff to be searched / sorted / tagged — all the common website stuff, but applied to private data as well
cuibonoboi don't think i have the time or mental bandwidth to grok native device apps, but i *do* subscribe to the app mentality: my website would be an app that consumes my public data API, posting would be through an app that has been registered with the API, etc.
cuibonobopdurbin: aha. so it needs to be indexed. fair enough. i'm actually between using flat files and then indexing with elasticsearch or using a database for both
pdurbin"Everyone should own and control their data. So when you make a web site on Branchable, we don't lock you in. You can use git to download the entire source code of your web site at any time, and move it elsewhere if you desire."
cuibonoboi understand that flat files allow for greater portability, but being able to search them requires building an index (or outsourcing to google) and the link between the files and the index can be very fragile
cuibonobopdurbin: well, i feel like there's a trade-off: search solutions that work very robustly with flat files generally can't do faceted search, i.e. only notes, stuff tagged with x
barnabywalterscuibonobo: why is it delicate? in my experience it’s the opposite, because if something goes wrong you can throw away the broken index and just rebuild everything
cuibonobobarnabywalters: nope. in mongo, each entry is a 'document' that doesn't need a schema, so a flat file storage dumped from mongo would look very similar to the flat files you use for your own site
cuibonobopdurbin: it should be json, but other than that there's no schema per se. so your document could very easily be `{"document":"your data here"}`
barnabywaltersaaron_pk: my current thinking is: ASCIIfy the name, if that already exists add the locality and city, if that already exists add an incrementing number
cuibonobobarnabywalters: hmm. the 'canonical' copy is something that i've also found confusing regarding the indieweb. this is digital data. there is literally no difference between the original and the copy besides the story in your mind
barnabywalterscuibonobo: there are huge, practical differences such as naming/addressing, access control, resolution, ease of backing up, ease of restoring from backups, etc
cuibonoboin my personal case, if i use mongodb for storage and each item has a unique id, i can dump the entire contents of the database to flat files as id001.txt, id002.txt, etc.
cuibonobobarnabywalters: backup of a backup? porting to some other backend? i'm not sure! i was just trying to illustrate that there was no practical difference between what would be in my 'database' and what's in my 'file system'
barnabywaltersat that point that copy is the canonical, “true” representation of the content, and all the other, non-canonical copies are out-of-date backups or indexes
cuibonobothere's a point where it's kind of blurry though, like if you post something that goes to a cache to be worked on before ending up in your store.
brianloveswords, frzn, fr0zen and vanderwal joined the channel
tantekaaronpk: since you're into self-recording a lot of stuff - have you seen http://www.reporter-app.com/ ? (developed by Feltron - what he used for the latest Feltron.com annual report)
tantek.comedited /Falcon (+436) "/* Working On */ combine the two repost of tweets tasks, move improve reply-context support to second spot" (view diff)
tantekin particular since this past weekend's restyling efforts, I've been thinking a lot about in-stream web action buttons (only indieweb example I know of is adactio.com right-aligned links at the end of each post to favorite, retweet etc.)
tantekhmm… I'm leaning towards use of "like" rather than the generic (but uncommon) "props", or the more strongly worded "favorite" (context: webactions verbs)
KartikPrabhuI have similar confusion about repost vs reshare. I realised that I don't want to 'repost' the entire post from somewhere else... but just reshare it my friends...
KartikPrabhutantek: yes then... my intent is to not 'repost' but then what is the word for that... Just telling your friends, 'this is a good post. read it' ?
KartikPrabhucuibonobo: I'm also interested in moving my notes from evernote to my site. Haven't quite figured out the private posts and log in bits yet
cuibonoboi have a bunch of stuff in it. the primary draw for me is 1) just writing a note. no need for titles or anything else. 2) tagging. 3) search. by far the most important feature.
cuibonoboright now i'm in an after-evernote phase where i'm dropping markdown files in a 2014 folder and using a timestamp as the title. i handle search through spotlight, but it's a little wonky
tantek.comedited /webactions (+3302) "why, how, add explicit markup example for how to add webactions to your posts (hope that helps make more happen!), move some background at the top to a history section, been long enough. and prefer like over props" (view diff)
tantek!tell barnabywalters not sure if it was you or not complaining about "props" but I now agree and have switched it all to "like" as the generic form, e.g. on http://indiewebcamp.com/webactions
tantekcuibonobo: apparently I actually documented the rant against "share" a bit more thoroughly on the wiki, with a bit of debate too! http://indiewebcamp.com/share
tantekeventually I get to "building wiki page support" for my own site: http://indiewebcamp.com/Falcon#Indie_Wiki but until then I don't really have a concrete suggestion to use one wiki software over another. :/
KartikPrabhutantek: are you sure you want to use those emoji things... not sure they show up in every browser and having a mystery square is not good UI.UX
tantekKartikPrabhu: your post ate a *ton* of heap memory, likely due to the SVG. So SVG still seems like an impractical memory pig. Not going to touch it.
KartikPrabhutantek: oh I see... did not know of that problem. in that case my indieweb post must be using monstrous amounts as all the illustrations are SVG too
tantekanother reason: browser UIs where the address bar is not (easily) accessible, e.g. mobile, or kiosk mode etc., and not having to scan back up to the top of the window for it either.
KartikPrabhutantek: isn't the 'not having to scroll' not relevant since on desktops the address bar is always present at the top, while in mobile you might have to scroll a little bit but the address is hidden per the first argument... So the second argument does not add anything really?
breti like it. although most url fields designed for sharing I avoid since its usually a disgustingly long tracking url... definately not the case with your layout though :)
tantekKartikPrabhu: the difference is that "scan" literally means what your eyes are doing, the muscle movement of your eyes scanning up - nothing do with with scrolling.