GWGSo, all my projects have always been to scratch my itch of getting it running, but I've tried to make the implementation open enough for others to be able to install
KartikPrabhuKevinMarks__: my only problem with the article is this: "Your life so far may have given you some idea what your prospects might be if you tried to become a mathematician" errr nope!
waterpigs.co.ukedited /friendly (+326) "/* How to make your site Indieweb Friendly */ removed duplicate, added linking domain name with content, subscriptions to indieweb sites" (view diff)
KevinMarksWondering if this is actually the killer feature for ello "you don’t get notified when someone responds to you, because there’s no system for notifications."
infpetal, friedcell1, pfefferle, musigny, squeakytoy and Sebastien-L joined the channel
ben_thatmustbemei should do that though, just make my post UI just an old style form, all just text, tables, and a white background. put in some CSS circles on the left to represent the 3 holes, and I'm good to go, haha
GWGtantek: You may remember this discussion at IWC NYC when I was interpreting pfefferle's code to add in the rendering, and generated the debate over the official/unofficial nature of the markup.
kylewmI'd guess sending webmentions to commenters would mess up just about every implemetnation right now (they'd interpret the in-reply-to post as a reference to the post itself)
ben_thatmustbemetantek, i thought about it. I specifically don't allow updating of reply-context though. I record content at first time of parse. I'd like to update this to store the exact data at time of reply though. but alas, that could get messy
cuibonoboso following the idea that i'm not actually modifying the page directly, but instead creating a post on /micropub so that your server can do the work on my behalf, POST makes sense
ben_thatmustbemeactually i just use the php libs from aaronpk, which i am not sure what it would do with a non-mf2 page. I think it might create it as a mention with everything except the URL blank
davidmeadI am. WP has been good so far but it’s starting to “get in the way” a little. I’ve been trying Known to see if it can replace WP as my main blog
Loqibenwerd: tantek__ left you a message 2 hours, 15 minutes ago: I found a good tablet UI for Known blogpost writing and scheduling: http://instagram.com/p/tptBeXG64g/ 😉
tantekand the weekly schedule nature - people like having some structure to place ideas for blogging and then having a reminder / nudge to blog them on a schedule
tantekand frankly, there are so many other things I'd rather be doing (in the physical world), that I do like the pressure to continuously make things *here* easier / simpler / quicker to implement and deploy
davidmeadGWG: problem i found with ‘press this’ is it doesn’t include the Social plugin. One of the main issues with the app. It’s fire, but I can’t edit it beforehand
tantekdavidmead: good summary of the problem: "the hurdle for me is copy & pasting tweet url’s into [my posting UI] to reply to them. Known['s bookmarklet] makes that a lot easier"
aaronpk_micropub and webmention are explicitly not RESTful, which has allowed a much greater degree of flexibility in backend architecture (for example allowing even static sites to use webmention and micropub)
cuibonoboaaronpk_: micropub is actually a good example of an RPC: to create a note i need to know to add `content`, `category`, and `syndicate-to` parameters
cuibonoboin a REST equivalent, performing a GET on a /notes endpoint will show you what a typical note looks like, and then you can use POST to create a similar document
aaronpk_that's actually basically the idea with micropub too. the parameter names are the microformat properties, so should all be discoverable that way essentially
cuibonoboa more RESTful approach would give more importance to the endpoints of the resources that you actually want to modify. so instead of POSTing to /posts/new, you would POST to /notes (or whatever)
aaronpk_I am firmly against RESTful URLs for micropub (see note about static sites and greater implementation flexibility above), but would be happy to incorporate some other design ideas from REST
cuibonoboaaronpk_: of course. it would be pretty much impossible to implement this on a static site. i personally prefer RESTful architectures because it turns permalinks into objects to be manipulated by the usual HTTP verbs we know and love
ben_thatmustbememy thoughts on rest. its nothing that but the usual GET/POST, you could easily implement the exact same thing with ?op=patch or something of that matter, and they aren't always supported. REST is just a published standard, we are making our own standard. Thats all
cuibonoboaaronpk_: i suppose it could! but as the current implementation works, if i encounter <link rel="micropub" href="https://something.com/link">, how do i know what that means?
aaronpk_so we could instead of defining micropub properties in the spec, we could say that any properties present in an h-entry can be used to create a new h-entry
aaronpk_I'm just saying that it seems like a roughly equivalent amount of knowledge between client and server is needed to support REST, so it doesn't seem any less tightly coupled to me
ben_thatmustbememy problem with REST is that to implement it you have to capture all URLs coming in. with MP your pages can be all static aside from your one MP endpoint page.
ben_thatmustbemeKartikPrabhu I don't see the two being really interchangeable at all. someone can certainly use a restful interface to CRUD all their data, but I think at that point its just a REST api
dlykeAlthough I have recently been thinking about all of these $1/mo limited RAM VM packages, and whether a special-purpose low resource web server tailored around IndieWeb-ish protocols might be the right way to go.
KartikPrabhuaaronpk_ I go to my /notes site and login there will be an interface to add a new note right there on top of my h-feed. Similarly, I click an edit button on current note and I can edit it right there. But somehow with micopub type stuff
ben_thatmustbemei have it coded up to read in a post from the DB, so if i'm logged in (owner only) and go to /new?id=<post_id> it autfills all the fields. I figure its easier to keep all the MP client stuff centralized
cuibonobokylewm: not necessarily. you can specify your Accept header to be whatever format you choose. the thing with a RESTful server is that it isn't necessarily stored as JSON, XML, HTML, or what have you
cuibonoboaaronpk_: this is what i'm doing for my own site. i haven't pushed my stuff to my actual website yet, but the dev version of my server can respond in XML, JSON, or HTML, depending on your Accept header
cuibonoboaaronpk_: at the moment i've got GET working for everything. POSTing and PATCHing nested data is hard. Also, how do i represent OPTIONS? very sticky
tantekcuibonobo: I believe there were proposals (e.g. for HTML5) to extend HTML forms to support more HTTP verbs, however, the lack of apparent real world (public web) usage of them made them uninteresting / hypothetical more than practical.
tantekalso observed that the industry was advancing the state of the art faster / better than PhDs (with the exception of a few fields like NLP, computer vision, robotics)
reedstrmHave heard a certain pundit on a podcast who uses his tween daughter and her friends as leading indicators. They consider FB a way to talk to Grandma. Using Dad's account.
dlykereedstrm: Friend's teen daughter: "Facebook is where I talk to people I know, but don't like, Tumblr is where I talk to people I like but don't know."
reedstrmI had the privilege of eating dinner seated next to Brewster Kahle several (many?) years ago, at a conference. He was an engaging dinner companion.
LoqiIndieArchive is a project to collaboratively grow an archive of pages replied to (possibly also mentioned) in indie web posts http://indiewebcamp.com/IndieArchive
tantek.comedited /database-antipattern (+1083) "/* Fragile */ subheads, clarify MySQL instance, add DB connection loss with Keybase and WordPress citations" (view diff)
reedstrmI'd think the correct approach for them would be to archive the WHOIS data for domains as well, and only honor robots.txt if the ownership matched.
benwerdben_thatmustbeme: Good, thanks! Concentrating on features for our hosted Pro accounts, as well as a few interesting general functions that address common questions
benwerdben_thatmustbeme: Best thing has been the feedback button in the top right of every page; we get a lot of emails every day, and they're all super useful.
benwerdreedstrm: Leo's show blew us away. It's responsible for lots of interest - although we also had demo day the very next day, as well as Gigaom and Wired.
cuibonobore: indiearchive, given all the parameters / algorithms that services currently employ to determine the content to show you, i wonder if at least the access location should be stored as well
cuibonobotantek: this is an interesting example. i had concluded to simply flatten my parameters and use dot notation. i.e. location.latitude, location.longitude
bret.iocreated /OWL (+163) "Created page with "<dfn>OWL</dfn> is the Web Ontology Language, a layer above RDF to define the classes and properties used in RDF, as well as to describe the relations between them."" (view diff)
cuibonobothe beautiful thing about verbs is that they describe action. removing verbs just pushes the vocabulary to either the object you're sending or the headers
tantekaaronpk - but how do you want to present it? publish some without explicit markup (e.g. in a note) and then we can analyze based on real world example(s)
kylewmcuibonobo: it makes sense to me to limit the HTTP verbs since you couldn’t possibly enumerate all the possible verbs some application might want. PUT, PATCH, DELETE seem very likely to be misused or bastardized for some slightly different purpose than intended
cuibonobokylewm: admittedly, I've only used HEAD, GET, POST, PATCH, and DELETE. those map nicely to CRUD too. i feel like the author of this article was just hungry for clicks.
bretaaronpk_: unless you wanted to tie in coffeetime with these meal metrics, (ie sending webmentions about 'dat coffee' so and so owes you) i dont see the purpose for having urls for each food item
cuibonobowe were discussing before that making all of your URLs responsive like that would be impossible on a static site. so micropub is responding to the situation in which it would be used
tantek__short answer, looks like the model of how PUT and DELETE in a <form> should work is undefined, and the door has been left open to someone (anyone) writing up an HTML5 extension specification that defines their behavior and then tries to get browser interested in implementing them.
cuibonoboKartikPrabhu: PUT and DELETE have a specific semantic meaning and when I sent a request with those methods, the server should always respond in the same way
cuibonoboKartikPrabhu: POST on the other hand, doesn't have that limitation. it's expected that the state of the server will continuously change if i continue sending POST requests
tantek__KartikPrabhu - you are referring to the chicken/egg problem. however note that plenty of standards have overcome that, so it's not a reasonable excuse.
KartikPrabhutantek__ it seems people who write specs are not interested in using it, and people who want to use it are not interested in witing a spec so it will be in this limbo forever
cuibonoboas i think about it more, i begin to realize that the needs of people and the needs of machines are different. removing everything but HEAD, GET, and POST addresses the needs of people (who are able to reason about sending form data twice)
cuibonobotantek__: RESTful architectures specifically push UI concerns to the client. your application needs to keep a cache of your recent operations and essentially PUT back any DELETEs, for example
cuibonobotantek__: it's interesting you mention gmail. in the app, unsend doesn't *actually* unsend. the app is simply waiting a predetermined time before sending. once the email is actually sent, you're SOL
tantek__cuibonobo re: "cache of your recent operations and essentially PUT back any DELETEs, for example" - in an unreliable network environment (the usual), that's not a reasonable assumption, especially without transactional integrity.
finchdundo with email is very hard, because allowing one user on this server to delete email (ostensibly the one they sent) from other people's inboxes on *all* other servers (or worse if they collect their mail on their personal machines (which may be offline)) is asking to get abused
finchdstoring all versions probably is the (between devices) answer, but only works on your site, it can't guarantee that it removes your POSSE/PESOS stuff from everywhere it got relayed to
cuibonoboin order to get undo from any device to work: create a post (version 1), delete the post (version 2), undo the delete (version 3 == restoring the data from version 1)
cuibonoboyour editing application should be aware of the context in which the user performed an action by keeping a time-limited cache. my primary data store doesn't need to know about any of that.
dlykeInteresting notion here of undo attached to a data store rather than a device... Although I'd suggest that some sites' time limited edit windows are similar...
cuibonobotantek__: ah. i realize why we disagree. "your data store needs to store whatever bits the UX needs to reconstruct the state for the user". in the interest of separation of concerns, i disagree with this.
cuibonobofinchd: in the model that i proposed, the server would simply store all the different versions of a piece of content. it's up to the application to make sense of those versions to provide a meaningful experience
tantekcuibonobo: separation of concerns is only useful when it helps implementation practice - otherwise it leads down the horrible path of java-style seemingly infinite call stacks.
tantekin this case, I'm positing that storing that information on the server (undo-ness, timing) actually simplifies implementation on both server and clients, likely improves reliability too. of course actual answers will have to await an actual implementation. so just opinion for now.
cuibonobotantek: indeed! all state about the *resource* should live on the server, which is why i call it my 'point of truth'. application and user states are another thing entirely
tantekeven as someone who might understand "application and user states" being different, I don't want to have to think about that. I don't want that cognitive load in a user interface that I myself use.
cuibonobotantek: if your application is well-designed, the user doesn't have to think about anything. server state lives on the server, application state lives on the application, and the user doesn't have to care about any of that
cuibonobofor example, if i have my gmail app open and disconnect my internet, the app knows that it can no longer communicate with the server and lets me know
LoqiVektra is a (largely) Heroku-compatible platform as a service (PaaS) that can be run locally on your own computer or "in the cloud" on a server http://indiewebcamp.com/Vektra
aaronpk_I hate this part of publishing new kinds of data. Whatever decision I make now is going to stick around for a long long time because it gets coded into things all over the place.
tantekif you just want to make up names and change things as you go along *without* first doing/documenting research, then h-aaronpk-* and p-aaronpk-* go for it. implementation experiments are also useful (independent of research)
dlykegregor`: Ugh, trying again... <img src=".*?\.jpg"> says "photo", u-featured says "this is a featured image", or this is a good image to use to represent the content on this page, or some other semantic meaning.