ノートに対する投げ銭機能 #6653
Comments
|
決済手段については、
から、暗号資産がよさそうだけど、私が暗号資産をまともに扱ったことがないのでよくわからない( |
|
暗号通貨手数料やばそう (物にもよるけど) |
|
あと暗号通貨を日本で扱う時素直にサービス側ウォレットを持つと法規制がめんどくMpurseとかで迂回しないといけないという問題もある (AskMonaがその辺でゴタゴタあった) |
どんな決済手段であっても手数料はかかる。一定の企業に手数料を払うよりはましかなと。
仕組みや概念として似ていそう |
|
AskMonaがどうして仕組みの変更を強いられたかというのは、AskMonaのサービス側でMonaウォレットを持っていたために資金決済法2条7項の四「他人のために暗号資産の管理をすること」に該当してしまうのでそうなったらしい？ 私が想定している実装では、ウォレットはユーザーが事前に作成しておき、Misskeyはウォレットアドレスやトランザクションハッシュ等を取得するがユーザーのウォレットの秘密鍵はMisskeyは把握しないようにする。なので、「他人のために暗号資産の管理をする」ということにはならなそう。 フリマアプリのように取引を媒介するものではあるけど、暗号資産の交換を媒介するものではないので『資金決済法における「暗号資産交換業」』ではない。 |
|
どっちの実装が良いんだろうか。どっちの方法でも、取引の確かさは同じだと思われる。
2のほうが無駄がないので、効率的な観点ならやはり2の実装になる |
|
P2P でやりとりするにしてもどっちにしろ受け取る側はウォレット開示する必要があるし送る側も送った時にバレるのでは (まあバレたところで…というのはあるが) あとトランザクションハッシュが本当にその投稿に紐付いたものなのかをどうやって検証するかという問題がある (検証しないと、例えば取引所等から本人のウォレットに送金した時のトランザクションハッシュを申請して、あたかも巨額をtipした人になる、みたいな悪用方法が考えられる) |
|
税務申告はどうするかというと、日本では、暗号資産の移動は資産の譲渡が行われた時の日本円での時価を基に所得を決める。つまり、どこかの取引所のAPIから時価を取得してあげる必要がありそう。……まあでも普通は1年に1回のことなので、Misskeyに組み込むプログラムではなく別のアプリとして提供すればいいのかもしれない。 Ref: 仮想通貨に関する税務上の取扱いについて; 国税庁 |
インスタンスのウォレットを介せば一般公開する必要はない…と思ったんだけど、結局インスタンスのウォレットのトランザクションを辿れば推察できちゃうわね。
Misskeyに保存されているウォレットアドレスをMisskeyアカウントと確実に紐づけさせて（通常の認証されたAPIリクエストでアドレスを送信するのでよさそう）、トランザクションに保存されている送り主と宛先の両方のウォレットアドレス（これが確かでなければブロックチェーンが崩壊する）を照らし合わせれば、とりあえず送り主と宛先のアカウントが本人たちのものかどうかは検証できる。宛先アカウントのどのMisskeyの投稿にトランザクションを紐づけるかは、送り主の自己申告だけど、そこを検証する必要性は低そう。 |
そのMisskeyアカウントの持ち主がそのアドレスを登録したということは確実になるけど、そのアドレスの持ち主がMisskeyアカウントの持ち主とイコールかどうかは |
|
「俺はこのアドレスからここにいくらだけ送るぜ！」というのを申請してからトランザクションを作ってトランザクションIDを送る (サーバーでは申請より後にトランザクションがあったことを確認する) という方式なら行ける気はするが別途専用アプリが必要になりそう |
確かにそうですね…そこまでして数字を大きく見せたい人は…いないとは言えないなぁ。 AskMona3の実装ドキュメントを見つけたので参考になりそう |
これやると絶対不正したいマン出ると思う |
|
あーまあアドレスの鍵で署名してもらえばいいのか。それでいいかもしれない |
|
あと今とりあえず気になるのは
くらいかなあ |
|
下心ベースで近々やりたい ETH+MetaMaskで実装すればいいんじゃないかと、テストネットあるし |
|
YouTubeのスパチャは文章をつけて投げられるわけだけど、どうしようかと思って。 私的には、返信してくれなかったとか嫌なコメントでも投げられてしまうとかでギスギスしそうなので、Misskeyでは単にお金を投げられるようにするほうがいいような気がする。 |
|
ギスギスはしないけど、投げ銭は減ると思う。 |
|
こういうのはMisskey本体じゃなくてMask Networkみたいな拡張機能に任せるのが一番な気がするけどな そもそも現状MisskeyはおろかMastodonにも投稿に投げ銭出来るユーザーがいるとは考えにくいけど。 |
|
文章でそういう人はあんまりいないとは思うけど、絵や曲を投稿している人はわりといて、そういう人にお金を払えるシステムと考えていただいたほうがいいかなと。 |
|
うーん、スパムが沸いて終わりになる気がする |
|
あと
は日本ではどれも当てはまってない気がする。 少なくとも身の回りでビットコイン決済出来る店舗なんてビックカメラぐらいだし |
|
ちなみにETHに関してはこの前Vultrのチャージに使ったけど、$10チャージするのに$30ぐらい手数料かけないと決済制限時間以内に検証かけてくれなくて使い物にならなかった（$30でもギリギリだった） |
|
|
|
そういえばそんなに高いんだっけ、誰だよこれ広めようって言ってるやつ |
システム（下限・上限金額の設定、暗号通貨のしくみとして返金がきかない、手数料で損失が発生する）とモデレーションで対応できると思ってる（モデレーションの負荷は増えるけど、その分はインスタンスに対する手数料で回収しようぜという感じ）
言ってはいけない
本人確認は一回すればいいし、Misskeyの中で回せば…と。 |
|
スパムに関しては乞食側のスパム |
|
スパム（中身bot）ではなくただの乞食では…？ 悪いことに頭が働かないのであんまり想像がついてないかも >< |
|
乞食botが大量にアカウントを作って自分自身をフォローしてユーザーが多いサービスをに見せたり |
|
|
↑それ |
|
そもそもETHを認知してる人がどれだけ居るのかって話しと、手数料の話もう忘れてない？ |
挑戦と無謀は違うんだよ |
|
↑ そういう懸念に対する回答です( そう、手数料問題が解決しない限り動けない |
|
そもそもな話が多すぎるんだけど、そういうので投げ銭ほしい人はpixivFANBOXとかnoteに行くと思うんだよね わざわざ変動しまくる仮想通貨でリスクを冒して+面倒くさい確定申告して投げ銭受け取りたいと思うユーザーが出てくるとは考えにくいな |
|
少なくともMisskey本体に実装する機能ではないというのが個人的な感想 |
|
ユーザーの為とか考えるなら、ココのメニューに自由な文字列とリンクを追加出来るだけで十分な気がする
|
|
ノートメニュー見ることほとんどないし使われないと思う
このissueはMisskeyインスタンスの収益化に対する一案として提案しているだけなので、それは言わないでください。 |
|
ん？ちょっとまって 手数料とれるプロセスなんて無くない？ |
|
|
それやり始めると資金移動業になるのでは |
|
1つのトランザクションに複数の送金を含められることを利用して、インスタンスのウォレットにも一定額を送金するようにする。インスタンスのウォレットに一定額送金されたトランザクションのみMisskey上で表示する。 と思ってたけどよく考えたらやっぱ普通に破綻してるな（手数料をとるだけのメリットを提供できなければ結局直接取引したほうが良いという話になる） |
MetaMaskで出来るのそれ
それはそう |
|
|
ETHではスマートにやるのは無理なことを理解した（ここにきて） |
|
メモ: Contract // SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;
contract MisskeyInstancePayment {
address owner;
constructor() payable {
owner = msg.sender;
}
function local(address payable addr) public payable {
uint256 fee = msg.value / 10;
addr.transfer(msg.value - fee);
}
function toRemote(address payable addr, MisskeyInstancePayment remoteAddr) public payable {
if (remoteAddr == this) {
this.local(addr);
} else {
uint256 fee = msg.value / 10;
remoteAddr.fromRemote{ value: (msg.value - fee) }(addr, msg.value, fee);
}
}
function fromRemote(address payable addr, uint256 input, uint256 remoteFee) public payable {
uint256 fee = input / 20;
addr.transfer(input - fee - remoteFee);
}
function payout() public payable {
require(msg.sender == owner);
payable(msg.sender).transfer(address(this).balance);
}
} |
|
実際にはfeeの割合を設定できるようにするのと、イベントを発行する必要がありそう Contractで多少節約にはなるけど600円～800円とかかかるのでやはり使い物にならない（gasが30k～40k、レートが200kJPY/ETH、gas priceが100Gweiとして） Ethereum2.0は解決されているらしいので期待 |
|
I didn't notice people were working on this. We forked Misskey and have been working on getting crypto inside. We are testing with OHMCoin but our system will allow for as many coins as. you like. So far we have wallets getting created for users and the ability to tip on notes. If its a renote the tip goes to the OG poster. Right now we have not really changed misskey proper, we are trying to just make it like a plugin but currently it needs the fork. We have a testing site up were you can make an account and check things out. Github Diff Testing site |
|
まじかよ （コード読んでみたけど、PoSの実際の実装をまだ理解できていないので、Intercom2の動作とかがあんまりわかってない |
|
its kinda simple. We have a wallet wrapper over the Ohmcoin (PoS) wallet installed on the server. The Master Misskey worker makes IPC calls to the Intercom Broker Worker locally to make things happen with the wallet. The wallet Wrapper is a Separate Daemon for the misskey master worker. If someone makes an action with tipping it forwards it to the master worker then triggers wallet wrapper to start the crypto trade function. Then the Intercom broker takes care of syncing with the Master worker and making the database updates. This allows us to keep the worker size down by not having a intercom broker on every worker. This will help if anyone decides to place misskey workers on crypto networks or places like Cloudflare. So all the posting and things can be done with no limits or slowdown and when tipping happens it routes to the main worker. The intercom Broker is sitting over the top of the wallet works as messaging system between the wallet, chain and misskey. It allows the records to be read and updated. It basically keeps the Chain wallet and Database updated. Every 4 minutes it scans the blockchain for new records to keep it up today. its Important because it allows us to run on the same server as misskey without having to major changes to the overall system. We are just adding some libs and things to the project like we did with the video.js implementation. That way it can be added or not added to misskey instances and keep fully in line with your overall code structure. There are basically 2 methods people use for Crypto to websites. We are mixing the 2 methods. Inter misskey tips are off chain but deposits and withdrawls are on chain. This will let us use any crypto we would like. Method 1: Fractional Reserve System
Pros:
Cons:
Pros:
Cons:
Method 2: On Chain Backed System
Pros:
Cons:
We are doing a test on test.ohm.tips then will be going live on gitmo.life Right now we aren't allowing people to tip remote instances but its something we can probably figure out with your help. It would be impossible expensive to go on chain with eth based on Price and Gas fees alone. It would really slow the down site having to put. Something like Cosmos network would be more helpful in a lot of ways but is still pricey. With this we could allow for eth wallets that people can tip out of and still allow them to withdrawl but they would have to pay fees. This Intercom system was made for Bitcoin but will work with just about any crypto on the market right now. This is just the start for getting Web3 on the system. So people can use metamask to sign in with their wallet |
|
サーバーが送金を代行できる形でウォレットを管理する("custody")のは、日本だと暗号資産交換業となっていろいろな法規制が発生するので、日本では使うのは簡単ではないのです。日本で使うならMethod 2しか選択肢がない。 |
|
I have looked into the Japan/US regulations and we have setup the system in a way that falls in line with their laws. Since we are using a mixture of method 1 and 2 we actually made sure to keep this in mind for you guys when doing this. To be considered a "Crypto Asset Exchange service" you have to fall into a couple of lines. I'll explain to the best of my ability. https://www.globallegalinsights.com/practice-areas/blockchain-laws-and-regulations/japan The term “Crypto Asset” is defined in the PSA as: proprietary value that may be used to pay an unspecified person the price of any goods purchased or borrowed or any services provided and which may be sold to or purchased from an unspecified person (limited to that recorded on electronic devices or other objects by electronic means and excluding Japanese and other foreign currencies and Currency Denominated Assets; the same applies in the following item) and that may be transferred using an electronic data processing system; or a. Sale or Purchase of Crypto Asset, or the exchange of a crypto asset; You have to be selling, buying or trading crypto assets for FIAT or different assets. 2 things we to no offer in any way. users are only able to send and receive the same type of currency and have no options to exchange or trade for any other asset. This is something that is similar in the US and we didn't wanna worry abou that. b. intermediating, broker or acting as an agent inrespect to the activities listed in item (a); We don't fall in this area since we aren't brokering transactions or transfers in respect to sale, purchase, or exchange. We are just offering a wallet application interface. c. Management of customers money in connection with activities listed in item (a) and (b); Since we aren't doing anything in A or B we aren't considered to be in the management of customers money since we only offer a wallet application interface for people to use to send the same crypto between the same type of wallet. d. Management of customers' crypto assets for the benefit of another person. Since we are only providing users with a crypto asset wallet application (Non-custodial wallet) and private keys our implementation does not constitute a crypto asset custody service. Since we are generating wallets for the users to interface with the website and giving them the control over custody of the wallet we are outside of the regulations on these types of systems, We kept that in mind when rolling this out with our mixed method. All deposits and withdrawals are on chain transactions initiated by the user and they are in full control of the assets. when they transfer to the tipping wallet it's still being managed by the end user as a wallet control system for protecting assets enabled by the user. So the main wallet is using Method 2 and when a user transfers assets to tip on the site it moves into a method 1 wallet attached to the method 2 wallet. When a user transfers their tipping wallet balance back to their method 2 wallet its fully managed by the user via the private keys they have access to. When a tip is made the transaction is staged with other tips and run on the blockchain when a few tips have been collected and sent as a 1 single multi output transaction settling the tipping wallet balances with the On chain network and keeping track of the microtransactions. The key here is the non custodial nature of the implementation |
Intercom2 is just a messaging bus, basically. It basically facilitates communication between the wallet daemon (i.e. Bitcoin core, or something like Ohmcoin) and the website. The "Broker" is what handles calls from the site and processes them through the bus. I will post more info and sources for Intercom2 soon.. As @defango explained some above. There are two ways to use this (Intercom2), and go about creating a crypto based wallet system. However, to do micro-transactions on chain is not entirely practical due to exponential growth of fees. So a hybrid system is used. I don't believe this system would be classified as a "Crypto Asset Custody Service" since it is "Non-Custodial" in design. Ideally, it is possible for users to hold a copy of their private key from the site, and the site would also have the key and detect any usage of it. I will do some research and elaborate more soon. |
Experimental Features - UpdateWe have merged gitmolife#11 and an experimental system implementation is live on @defango's instance There is ability to tip on notes, and it seems to work with the federation network fine so far. The tip option does not show on remote notes, or on notes that you have posted yourself. It will also show the amount tipped on/to the note, and turns orange if you have tipped that note. The relevant source code for the crypto implementation into Misskey is currently located in a side-branch for review. If there is interest and such crypto features desired in a more general form for other instances (and possibly coins), we can work on a more formal implementation of this system and put together a PR for upstream Misskey. This would include optional support for usage and customization of, with different modes of operation to accommodate various region(?) requirements. Quick OverviewIntercom2 is a two-directional messaging bus which supports secure socket communication and allows for message payloads to be sent to and received by connected applications in the bus network. Below is an updated layout diagram of the current underlying major components that make up the instance. I clarified some labels.
We will be finalizing and putting together a release for Intercom2 repository and development usage documents soon. If there is significant interest in inclusion of cryptocurrency into Misskey, I will work on putting a proper merge request for that as well. Please let me know.. 🙂 |
|
In case anyone is still interested in this, I've implemented subscriptions in my own project Mitra: https://codeberg.org/silverpill/mitra |
|
いらない |
|
リノートとリアクションだけでは表現できないくそでか感情をぶつけたいのでやりたい |
|
revisit: 特定商取引法関係が面倒そうなので外部プラットフォームに誘導するぐらいにしたい (個人的な意見) |
Summary
私は日々「Misskeyを収益化する」ことを漠然と考えているのですが、その一案として、「ノートに対して記事購読料を払う」という感じで、ノートに対して購読料を払う（投げ銭をする）機能が実装できたらお金の動きができるのではないかと思っています。
特定のサービスに頼るのはどうかと思うので、ETHとMetaMaskを用いるのがいいのかなと。
※ Misskeyのバックエンドに暗号通過の秘密鍵を送信するようなシステムは本人認証が必要だが、公開鍵やアドレスを保存するには当然問題ないはず
Ideas
The text was updated successfully, but these errors were encountered: