| 12 Dec 2018 |
 cicalese | SMWCon is live streaming: https://www.youtube.com/channel/UCp_4oQP0vgeeubu3qrP-Ifg/live | 15:32:19 |
| cicalese | The day is almost done there. The dokit presentation, especially, was great! | 15:32:48 |
| cicalese | I only joined midway through the BPMN presentation. I look forward to going back later and seeing the earlier ones. | 15:46:30 |
 hexmode | Today in hexmodem's paradise: $CLIENT sent out emails with the link to a tracking pixel that had been uploaded to the wiki. Images are behind img_auth.php which blocks caching. | 21:13:36 |
| hexmode | Looks like we got 100,000+ requests for 5000 emails | 21:13:55 |
| hexmode | dokit? | 21:20:32 |
| 13 Dec 2018 |
 tgr | how did they expect to track it? | 07:02:28 |
| tgr | img_auth is not throttled? | 07:02:50 |
| hexmode | tgr: co-worker manages the logs there, so requesting an image and adding an identifying query string made sense for him. | 13:42:57 |
| hexmode | throttling? pshaw.... no, I'm pretty sure the problem was some code I had that wasn't caching correctly and made a few db queries. | 13:44:02 |
| hexmode | random email from someone who was upset with User:Metalhead64 on wikipedia for some reason. | 18:31:24 |
| hexmode | "Susan" claims to be AllThings.Go and somehow convinced herself that I was Metalhead | 18:32:32 |
| hexmode | Anyonee know about this wiki-drama? | 18:32:49 |
| hexmode | She's interested in machine translation. I would ask nikerabbit but I don't want to unleash the rando on him. | 18:34:39 |
| hexmode | Evidently she's involved in yet-another Wikipedia clone. Larry Sanger is involved, but this one is based on BLOCKCHAIN | 18:52:17 |
| hexmode | how can they not win? | 18:52:23 |
| hexmode | https://everipedia.org/ | 18:52:33 |
| hexmode |
Democratic Proof of Stake (PoS) model allows for voting to change and upgrade the IQ network as it grows. Also will facilitate batch imports of new content with no fees.
| 19:37:23 |
| hexmode | PoS isn't democracy | 19:37:36 |
| hexmode | its a pos | 19:37:41 |
 Bryan Hilderbrand | Sweet! Yet another token! | 19:50:37 |
| hexmode | I love tokens | 19:54:57 |
| hexmode | the entry for Blockchain on Everipedia was 404 when I checked. | 19:55:25 |
| hexmode | ominious | 19:55:28 |
| hexmode | Whenever I go to chuck-e-cheese (never, my kids are way too old) I stock up on tokens. | 20:05:21 |
| 14 Dec 2018 |
 rundg | if customer EXAMPLE has a wiki at www.example.com/wiki and wants to outsource the wiki hosting (meaning that the wiki lives in a separate DataCenter), what are the options for retaining the existing URI structure as indexed by Google etc. Let's assume that the outsourced wiki is accessible directly at the new subdomain: 'wiki.example.com/wiki'
I believe the options are:
a) Proxy. Have the 'www' server proxy all requests (internally) to wiki.example.com; thus mapping those requests onto the pre-existing www URIs so that to the outside world (users and Google), the URIs are unchanged. The downside of this approach is the added network latency of proxied requests to the wiki subdomain.
b) Don't proxy. Redirect permanent instead. This changes the URL structure visible to both the user and the search engines so there would be a permanent loss of 'Google Juice' associated with the 'www' subdomain.
Is this correct? Has anyone tackled the same issue before? Have I missed options or details? | 16:45:21 |
| hexmode | permanent redirects are probably best | 19:11:44 |
| hexmode | I haven't dealt with it, freephile , but it permanent redirects are what I remember from history | 19:12:25 |
| hexmode | and proxying might introduce latency that Google wouldn't like. | 19:12:45 |
| tgr | redirects, definitely. Google will punish you for duplicate content. | 19:53:38 |
