Slack archive

cofacts

Month: 2020-04

2020-04-01

caasi 00:40:19
cofacts 好厲害！ https://cacm.acm.org/magazines/2020/4/243640-detecting-fake-news-in-social-media/fulltext

cacm.acm.org

Detecting Fake News in Social Media: An Asia-Pacific Perspective

Many of the latest techniques to automatically debunk fake news were initiated in the Asia and Oceania region.

感謝分享~~~

文章這個段落：
> Intelligent fact-checking chatbots that incorporate a GAN to retrieve and generate natural-language evidence and explanations, such as the Cofacts program in Taiwan, are being progressively developed and implemented on IM services to catch false information and prevent it from spreading instantly
用 GAN 生成闢謠也太夢幻，作者可以不要用 ACM 雜誌許願ㄇ
Gan不都是生圖像，生文章可以嗎
文章可能還有點難，詩和句子的話有：https://www.ai-fragments.com/
gary96302000.eecs96 2020-04-02 17:46:19
寫小說的有 不過就是沒有中文的 而且有時候前後文不太有關聯
🐳 4
mrorz 10:59:45
感謝分享~~~

文章這個段落：
> Intelligent fact-checking chatbots that incorporate a GAN to retrieve and generate natural-language evidence and explanations, such as the Cofacts program in Taiwan, are being progressively developed and implemented on IM services to catch false information and prevent it from spreading instantly
用 GAN 生成闢謠也太夢幻，作者可以不要用 ACM 雜誌許願ㄇ
😂 1 🐛 1
mrorz 11:01:49
話說 GAN 不是 deep fake 的核心技術之一嗎

那 GAN 生成的針對 deep fake 的闢謠
484 該叫 deep fake fake (?)
gary96302000.eecs96 2020-04-02 17:48:02
Deep fact如何 XD
Stimim 11:25:51
可是這種迭代本身就是 GAN 架構的一部份不是嗎 😅
對 lol
mrorz 13:41:07
今天會議記錄：https://g0v.hackmd.io/IS6_Qg6pQFK6uorTtatZ7w

要決定小聚、還有 LINE bot 的一些 memory issue 討論。

我跟比鄰今天會在 Workis，然後也會開 Powercall ( https://tico.chat/powercall?room=cofactshack&type=timeFirst ) 唷。

g0v.hackmd.io

20200401 會議紀錄 - HackMD

tico.chat

Tico | Where better conversation happens

The considerate messenger. Chat with whom you care about always at the best moments and times

我今天要請假，我公司今天要趕東西上線
好喔平安
yanglin 17:41:09
今天晚上開會嗎？
bil 18:32:12
開會唷
mrorz 20:15:12
剛才電腦斷電
現在回來惹
@acerxp511 還在嗎 ~~
stbb1025 21:17:58
我有聽到聲音
mrorz 22:10:01
法人名字規定
https://m.facebook.com/story.php?story_fbid=227849687561011&substory_index=0&id=203494753329838

過去的討論串
https://beta.hackfoldr.org/cofacts/https%3A%2F%2Fhackmd.io%2Fs%2FH1we3AgTg
https://github.com/cofacts/rumors-api/issues/28

- 真的假的研究會
- 台灣公民科技協作查核協進會 / 協核會

m.facebook.com

申請設立協會互助園地

【協會名稱】 取名時應注意： ＊若是地區性的，要加上台北市..等 ＊若是全國性的，要加上＂台灣＂或＂中華民國＂等字樣。 ＊在未立案前，先不需加上＂社團法人＂字樣，這是於立案完成後，再去法院申請的法人身份。 ＝＝＝＝＝＝＝＝ 內政部關於名稱的規則如下： ＊名稱得使用部分非中國文字或部分簡稱(如：E時代)，但仍以使用中文全稱並開頭冠以組織區域為宜。...

2020-04-02

mchen15 02:48:55
@mchen15 has joined the channel
chihao 10:58:27
`協核會` 😄
十劦木亥協會
bil 13:38:05
鞋盒會
mrorz 18:30:29
spark joy
mrorz 18:33:16
目前 LINE bot state diagram 長這樣：https://docs.google.com/drawings/d/1GIuprSEGpthMW6KuCgawMky5Nnxm7P7mlxeODPdA-lI/edit

根據 3/25 的討論，我們會用 LIFF 來詢問文章來源與理由。

重新設計之後，新的 LINE bot state diagram 會像這樣：https://docs.google.com/drawings/d/1sSzI0PSggkA3PPP99Nl18H4zMO4lk-2y5s7dGRNJwAE/edit

幾個重點：
• 共有三種 LIFF： LIFF asking source (詢問文章來源)、reason LIFF (送出文章理由)、feedback LIFF (覺得回應有用的建議或沒用的理由)
• 送出 article, reply request 與 feedback 的流程思維改變：從先問理由(選填)才送出，改成先送出、才問理由。回到 `__INIT__` state 時，也能叫出 LIFF 修改 reason / feedback。這也導致了 state diagram 的簡化，直接刪除了 `ASKING_XXX_REASON` 的 2 個 state。
• 在 LIFF 裡的動作（選擇選項、送出文字）都會透過 LIFF send message API 傳回聊天視窗做紀錄；同時 chatbot server 也會把握這個機會拿到新的 reply token 送新東西（也就是 state diagram action 裡的 “reply with” 敘述）
• 光是顯示 LIFF 是無法回應使用者的，但可以在 LIFF 載入時打 API 進行動作（如 create feedback）
• 設計時需考量到使用者跳出 LIFF 之後怎麼回來接關。
🦒 1 🐳 1 🚀 1
lucien 23:53:56
1. 個人頁技術上想實作使用者之間的 follow ，具體上功能 follower 可以看到主人的查核消息
2. 列表分頁根據現在的技術架構，決定使用 infinite scroll ，如果有餘力改成多頁 (offset )形式再試試
3. 等級名字重新徵求討論，因為我們接下來要來畫等級 badge ，有些看起來意義不明 https://github.com/cofacts/rumors-site/blob/dev/constants/levelNames.js

GitHub

cofacts/rumors-site

Rumors list / creation UI, with server-side rendering - cofacts/rumors-site

follow 可以用 RSS 訂閱就好ㄇ
缺點 (也不一定是缺點) 是不知道誰是 followee
想要介面上導入社交性，我覺得可以存mongodb
我自己是有遇過「這個編輯寫的東西不太 ok，所以他出東西我想要第一個知道」的需求，但這種時候我不想跟那個編輯交朋友 XD”
哈哈好
那RSS可以滿足你的需求
我現在要做的方向是強化編輯的主體性
所以之後組織帳號跟個人職業認證會慢慢導入
我覺得無可避免會需要新的資料庫
1

2020-04-03

jmonk 14:14:18
@jmonk has joined the channel
mrorz 17:20:48
LINE bot server 的 GraphQL 與目錄結構也訂好了：
https://g0v.hackmd.io/860RnxUGTi6z2Kca6ojAbg?both#LIFF-API

為了因應增加 LIFF & GraphQL API，之後 rumors-line-bot 的目錄結構會調整如下：

- `/liff`: 資料夾位置不變，但裡頭改成 svelte client-side app config w/ Webpack
- `/i18n`: 資料夾位置不變。
- `/src`: Chatbot server 本體。
- `index`: koa server 進入點。
- `handleInput`, `handlers/`, `checkSignagureAndParse`, `lineClinet`: 移動到 `/src/webhook`，亦即 LINE messaging API webhook。`/src/webhook/index` 擺放目前在 `src/index` 裡的 `singleUserHandler()`、`groupHandler()`、`processText()` 邏輯，使 koa server 進入點不要放太複雜的 middleware logic.
- 新增 `src/graphql` 放 Apollo server 相關 typedefs；`src/graphql/index` 為 GraphQL API request handling middleware。
- `ga`, `gql`, `redisClient`, `rollbar`: `graphql` 與 `webhook` 共用的東西，移動到 `/src/lib`

g0v.hackmd.io

Cofacts LIFF redesign - HackMD

👍 2

2020-04-04

mrorz 08:38:58
PR 來囉
https://github.com/cofacts/rumors-line-bot/pull/167

GitHub

Restructure files under src directory by MrOrz · Pull Request #167 · cofacts/rumors-line-bot

As planned in redesign doc, we are restructuring files to make room for GraphQL APIs. This is the prerequisite for #144 . Changes include: Introduce babel-plugin-module-resolver and pin resolve ro...

mrorz 18:20:33
LINE bot server GraphQL: https://github.com/cofacts/rumors-line-bot/pull/168

因為 LIFF API 要 auth 比較複雜，所以先寫了不用 auth 的東西（之前提到的公開 insight API）來建立 LINE bot graphql server 與 unit test 架構，請過目。
PR base 暫時戳進 #167 的 branch，這樣 code diff 比較單純、比較好 review；167 進了之後這個 PR 也會把 base 改到 `dev`。

GitHub

Add GraphQL insight APIs by MrOrz · Pull Request #168 · cofacts/rumors-line-bot

This PR adds simple APIs that do not need nonce, and adds unit tests setup. Fixes #155 Input { insights { messageDelivery(date: "20200401") { status broadcast targ...

ggm 18:44:26
```// Export for custom resolveEdges() and resolveLastCursor()
//
export function getCursor(cursor) {
return Buffer.from(JSON.stringify(cursor)).toString('base64');
}

export function getSearchAfterFromCursor(cursor) {
if (!cursor) return undefined;
return JSON.parse(Buffer.from(cursor, 'base64').toString('utf8'));
}```
ggm 18:45:44
@mrorz 為什麼要做 base64 的 serialize 呀？elasticsearch 不是直接丟 array 進去嗎？
我的 articleCategoriesByCategoryIdLoaderFactory 的 pagination 是直接吃 array 進去，我有點不懂為什麼要轉 base64 XD
然後我不確定 Category.articleCategories 不知道要不要用 loader，或是維持現在就好
@ggm cursor 加 base64 是 Facebook 官方推薦這麼做的：
> As a reminder that the cursors are opaque and that their format should not be relied upon, we suggest base64 encoding them.
其他用到 cursor 的都有這麼作呢
雖然可能比較正規的做法是寫個 custom scalar 給 `Cursor`
parse value / serialize 的時候就直接 base64 轉進轉出
就可以不用在 resolver 裡面處理這個了
噢噢原來是 graphql 的建議
PR 又更新啦～
mrorz 23:45:34
LINE bot server GraphQL 加上 user context API 與 auth 邏輯囉：
https://github.com/cofacts/rumors-line-bot/pull/169

GitHub

@auth directive and context API by MrOrz · Pull Request #169 · cofacts/rumors-line-bot

This PR implements a GraphQL API, Query.context, that will replace the current /context/:userId API endpoint. As designed in design doc, we authenticate the user by Authorization header. When userI...

2020-04-05

mrorz 12:34:34
昨天想到，使用者選到一則沒回應的訊息有兩種情形：
1. 有複數篇訊息符合搜尋，而使用者點到沒有回應的那篇
2. 只有一篇訊息符合搜尋
2 的行為，現在是直接跳到「沒有回應噎，請按『我也想知道』」這一步。

我思考了一下，原本 （3/25 會議時提出的） 1 直接打開 LIFF 的設計，其實也要處理「把使用者選了這一則訊息（`selectedArticleId`）存進 context」這件事。但是，目前 chatbot webhook 的設計都是「回應時一併 mutate state 與 context」，但這個設計會需要在不改 state 的情形之下修改 context，我覺得設計上不是很好。況且，2 「只有一篇訊息符合」的 case 也無法解決，因為我們沒辦法在回應訊息時直接打開 LIFF，無論如何都要吐一個按鈕出去讓使用者點才行。

因此我還是把 `ASKING_REPLY_REQUEST_REASON` 這個 state 加回來了：
https://docs.google.com/drawings/d/1sSzI0PSggkA3PPP99Nl18H4zMO4lk-2y5s7dGRNJwAE/edit

• `CHOOSING_ARTICLE` 下，不管是上面 1 還是 2 的狀況，都會轉移到 `ASKING_REPLY_REQUEST_REASON` state 並且設定 `selectedArticleId`
• state 轉移的當下就會送出 reply request。
• 作為 reply，我們會告訴使用者「抱歉『ooooo』這一篇還沒有回應，已經幫你提交需求」、並且問使用者願不願意提供更多資訊幫助編輯闢謠（一個按鈕）；按鈕會展開 LIFF asking source。
• 續上，使用者在 `CHOOSING_ARTICLE` 下到底選了「哪一篇」在對話視窗裡面就會有個紀錄（LIFF 下比較麻煩還要 `sendMessage`）
這樣一來，整個流程也會與流程圖右邊的 `ASKING_ARTICLE_SUBMISSION_CONSENT` 更為接近，但差異是 reply request 會在進入`ASKING_REPLY_REQUEST_REASON` 之前就會觸發（加速 1 人回報 --> N 人回報的過程，反應實際流傳度 ），而送出文章是在離開 `ASKING_ARTICLE_SUBMISSION_CONSENT` state 的時候才會觸發。
bil 15:02:16
欸是不是所有的https://hssszn.com/都建立資料庫連線時發生錯誤

讚新聞全部被移掉了嗎囧
他們倒站吧
mrorz 16:20:30
LIFF 用 mutation API 的 PR:
https://github.com/cofacts/rumors-line-bot/pull/170

mutation API 砍到剩兩隻。
其實我覺得 `submitArticle` 應該也沒有需要，使用者 LIFF 裡點擊 source 之後會 send message，我們應該在這個 send message 的 webhook 裡面送出文章就好，不需要透過 GraphQL。 因為送出 article 需要 article ID 才能產出 webhook 回應，不如直接在 webhook 裡送出文章拿 article ID，會比做在 LIFF 直接。

GitHub

GraphQL Mutation API for LIFFs by MrOrz · Pull Request #170 · cofacts/rumors-line-bot

This PR implements submitArticle and voteReply mutation, which are invoked directly in LIFF.

想了想還是砍掉 `submitArticle` 讓 API 單純些。

2020-04-06

2020-04-07

Fiona Huang 00:26:42
@fiona.hgworld has joined the channel

2020-04-08

mrorz 00:00:38
category API 可以 merge 了！！
不過有個大問題：UI 端的 article list category filter PR 一定會跟 @yanglin5689446 正在實作的 article list 撞⋯⋯

https://github.com/cofacts/rumors-site/pull/218

這裏有什麼進行 merge 的想法嗎 QQ

GitHub

Article list category selector by MrOrz · Pull Request #218 · cofacts/rumors-site

Implements part of #213 . This PR also moves ArticleListPage components to under components/ArticleListPage, so that article list logics are not mixed up with component implementation in pages/art...

❤️ 1 🦒 1 🐳 1
mrorz 00:01:33
我在想是不是該直接丟掉這個 article list PR 然後直上 @yanglin5689446 的 article list
mrorz 00:02:13
然後還沒拉皮的 article detail 可以 merge (但沒人 review 囧)
https://github.com/cofacts/rumors-site/pull/234

GitHub

Category list in article page by MrOrz · Pull Request #234 · cofacts/rumors-site

Implements Article page UI in #213. List article categories under article text & reply request list. The person adding the category (canUpdateStatus === true) can remove category (has delete b...

conflict resolved, 求 review
mrorz 00:03:13
另外，這裡有升級 next.js 來修正 vulnerability 的 PR。
升級時也同時有丟掉一些 polyfill
https://github.com/cofacts/rumors-site/pull/245

GitHub

Update dependency next to v9.3.2 [SECURITY] by renovate · Pull Request #245 · cofacts/rumors-site

This PR contains the following updates: Package Type Update Change next (source) dependencies minor 9.1.2 -> 9.3.2 GitHub Vulnerability Alerts CVE-2020-5284 Impact Not affected: Deplo...

這個先 merge 了，我其他 PR 要用裡面的東西
yanglin 00:04:58
衝撞可以我 merge 或 rebase
mrorz 00:06:00
如果你 article list 已經開工了的話那理論上我 article list 那個 PR 應該可以不用進
你可以看看有沒有什麼 refactor 值得揀進你的 branch 裡，然後我的 article list PR 就直接 close without merge?
👌 1
yanglin 00:06:26
好那我 cherry pick 進來改
mrorz 00:06:28
article page 的倒是可以 review 一下，沒問題就進
mrorz 00:07:18
navbar ui 的 PR 只差修 conflict 囉
mrorz 01:04:51
@ggm category API 要 work 的話，至少會需要把新的 article category feedback, category 等空 index migrate 到 production DB
會需要一個 migration script 建立這些欄位與 index 呢
mrorz 01:05:56
conflict resolved, 求 review
mrorz 18:35:12
Channel access token API 更新
https://developers.line.biz/zh-hant/news/2020/04/06/channel-access-token-apis-v2-1/

developers.line.biz

News: Channel access token v2.1 released

We released the latest version of the channel access token. This new version lets the user specify the expiration date and also provides security enhancements by switching to using a JSON Web Token (J...

Oz 19:06:10
@oguzhan has joined the channel
stbb1025 19:37:53
https://www.figma.com/file/zpD45j8nqDB2XfA6m2QskO/Cofacts-website?node-id=432%3A2019
@lucien @yanglin5689446 @mrorz 本週主要針對搜尋頁面做補強
有任何問題麻煩隨時跟我說唷～

Figma

Cofacts website

Created with Figma

❤️ 3 🦒 1 👍 1

2020-04-09

mrorz 00:13:21
LINE user 呈現在網站上的頭像與假名生成
https://g0v.hackmd.io/7ERem43XREWJPOjjdE28SQ

g0v.hackmd.io

頭像與假名 - HackMD

那個名字生成出來好像會變得有些中二
這…. 出現手繪賓果機
對呀我覺得他們的 generator 字典很棒
只是不知道能不能直接拿來用 XDD
我記得他們固定是用「來自${place}的${adj}${name}」
repo 沒有 LICENSE 哭哭
Fang 18:01:45
@housemanfang has joined the channel
mrorz 18:22:11
Svelte LIFF 設定也好囉
https://github.com/cofacts/rumors-line-bot/pull/171

GitHub

Svelte setup for LIFF by MrOrz · Pull Request #171 · cofacts/rumors-line-bot

These are included in the PR: Svelte localhost & production build i18n extraction and resolution integration (ttag requires webpack, cannot use rollup) Material design component (via svelte-ma...

👍 2

2020-04-10

yanglin 00:21:58
求救為什麼我照 argument 跑會出這個錯 QQ
截圖 2020-04-10 上午12.20.12（2）.png
這個 API 的回傳是一個 articleReply
articleReply 本來就沒有 vote，只有 articleReplyFeedback 有～
原本是為了利用 apollo-client 的 automatic cache update 來更新被評價的 articleReply

只是我讀了這篇才知道
我們 mutation 回傳值設計其實還可以更好
所以那個 body 裡面要用 ownVote 囉？
`ownVote` 跟 `vote` 不一樣呀 @@

• `vote`: `articleReplyFeedback` 的欄位，紀錄「下了這個 `articleReplyFeedback` 的人」的那個 `vote`。
• `ownVote`: `articleReply` 的欄位，紀錄目前登入的使用者（呼叫 API 的人）針對這則 `articleReply` 的 `vote`。API 的 resolver 裡頭，他其實背後是去把當下使用者針對這則 `articleReply` 的 `articleReplyFeedback` 撈出來然後回傳他的 `vote`。這個欄位的存在，就是為了讓 UI 不用大老遠把所有 `articleReplyFeedback` 透過 API server 弄到瀏覽器來過濾，而可以直接拿到一個值用來判斷「目前此使用者，覺得這則 articleReply 是有用還沒用」。
因為目前 `CreateOrUpdateArticleReplyFeedback` 回傳的是被評分的 `ArticleReply`，所以 body 裡面有的是 `ownReply` 欄位。
喔喔
我回家再看一下 schema XD
右邊有 schema 按鈕，欄位有 description 可以看～

這裡也有列出 schema definition，只是沒有 syntax highlight XD
我知道 只是我現在用公司工作機沒環境 XD
我自己兩邊都裝一樣的環境，VS code 還用 settings sync 把設定與 extension sync 起來 XD
Relk Li 16:03:12
@zxc140zxc140 has joined the channel

2020-04-11

yanglin 14:51:30
想問一下要怎麼手動更新 graphql cache
我現在用 useMutation ` CreateOrUpdateArticleReplyFeedback` 成功創建了回應
但是 reply feedback count 並不會更新