イラストレーターがモナカードを始たら良いかもしれない理由
モナカードについての説明記事は多いですが、何が目的でモナカードを始めることになるのか？というがないのかなと思ったので解説してみます。今回はイラストレーターさんの立場で魅力を解説します。 みんなにもらってもらえる楽しい！モナパちゃんというTwitterでの配布を自動で行ってくれるアプリケーションの助けを借りれば自分の作ったカードをみんなに配れます。みんなが喜んでもらっていく様子を見るのは楽しいものです。もちろん直接送りあうこともできます。自分のイラストを物のように送れるって何か面白くないですか？ 小遣いを稼げる！モナカードを支えるシステムには自動販売機能があります。例えば1MONA払われるとカードを自動で送るという設定ができます。1MONA～10MONA(1MONAは約200円)くらいなら、まあまあ売れますので売る枚数によりますがうまくいけば数千円～数万円くらいの小遣い稼ぎになります。今までTwitterやPixivなどで披露していた絵がプラスでちょっとしたお金になるっていうのは結構うれしくないですか？ カードとして記憶に残るイラストに限らず作品は出来たときはみんなに見てもらったりチヤホヤしてもらえますが、時間がたてばだんだん忘れられていきます。素晴らしいイラストが次々に消費されていくのは寂しいなと思うところがありますが、カードにしてみんなに売ったりあげたりすれば仮想ではありますが、作品の寿命を延ばすことができるのではないかな？と思います。 自分はイラストレーターではないのですが、開発者の立場から想像して書いてみました。今回の記事では仕組みや使い方は解説していないので知りたい場合は別途ググってください。気になったらまずはモナパちゃんがTwitterで配布してる気になるカードにリプしてもらってみたりしたら良いかもですね。
モナカード VS Ethereum NFT画像
モナカードを使うかEthereumを使うかどっちが良いでしょうか？ 手数料手数料はモナカードがただ同然なのと比較してEthereumだと数千円~万円レベルでかかってしまうので金銭的な気軽さは全く異なります。ここが大きな違いの一つですね。 エクスプローラーやウォレットどちらも使いやすいものがそろっていますが、トークンのという意味であればEthereumの方が圧倒的に良い環境だと思います。NFT画像のという意味ではそこまで大きな差はないように感じます。 永続性どれだけ長い期間プラットフォームを維持できるかは重要です。永続性を評価するにはトークン、画像、プラットフォームの寿命を考える必要があります。寿命の長さはトークン>画像>プラットフォームとなりますので、まずはプラットフォームの寿命を考える必要があります。永続性はEthereumのシステムの方が圧倒的に優位のような感覚がありますが、プラットフォームの寿命を考えると単純に比較するのが難しいです。プラットフォームが終了することは今までもありましたし、今後も普通に起きると思います。そうなったらトークンに永続性があってもほぼ意味がないですね。したがってどちらの方が永続性があるかは評価しにくいです。ただし現在はモナカードがimgurを採用しているのでそこが気になる方にはデメリットとなります。 購買力これは圧倒的にEthereumの方が高いですね。数億円レベルのNFTも売れていたりして資金力が比較になりません。モナカードも数万円くらいなら稼いでいるユーザーの方もいるので全くお金にならないということはないのですが、一攫千金を夢見たりNFTを仕事にしようと思ったらEthereum一択という感じです。 NFTを使った遊びや配布などEthereumだと何か遊びはあるのでしょうか？例えば自動で配布したりガチャがあったり、交換したり。ここら辺は勉強不足なのでEthereum側のことはわかってないのですが、モナカードには遊びを提供しているサービスがあるのでそういった機能を使いたい場合はモナカードを選択する動機になりそうです ユーザー数Ethereumは全世界で使われていますがモナカードだと日本の限定的なコミニティがメインになってしまいます。コミニティが見渡せる範囲だといいうのは居心地がよいものですが、世界に羽ばたきたい場合はEthereumの方が圧倒的に優位ですね。 どちらを使うべきか？天下のEthereumのNFTと比較するのはおこがましいような気もしてしまいますが、比較してみるとモナカードを使う方が良い場合というのも結構ありそうです。モナカードは手数料が安く手軽に発行できることや楽しく使えるサービスがあることが魅力だと思います。モナカードはマルチポストを許可しているので、Ethereumのプラットフォームの方でも可能であれば両方に投稿して比較してみると良いかもしれません。何か間違いがあれば
吉田嘉明DHC会長がハッキリ意見を言うことがどれだけ凄いのか
まずは先日Twitterトレンドに興味深い文章が表示され、幸いにも一次ソースに容易にあたることができたので引用するとともに画像にて再掲致します ヤケクソくじについてーDHCオンラインショップ https://top.dhc.co.jp/contents/other/kuji_about/?sc_iid=main_banner_kuji 画像 感想：責任者は普通本音を言わない 会社の社長さん、会長さんって一番わがまま言える立場と思われるかも知れませんがむしろ逆で、社員達の生活も預かるわけですし、会社も存続させなければいけません。多くの場面で会社にとって損得を考えながら動きますし、自分で決めた会社の理念に反していないか、自分自身の生き方に反してないかアクションひとつひとつ注意して動きます。そうなると、普通あまり波風の立つこと言わなくなります。会社の業績が悪化するかも知れませんし社員一人一人の生活を危険に晒してしまうからです。今回のDHC会長の意見はまずこういった明確なメッセージを出したことそのものが凄いと思います。 多くの場面で正面から戦うことは商売人はしないと思います。民間企業が価格や商品やサービスで差別化してるのは戦っているのではなく戦わないようにしているのだと私は解釈しています。だからDHC会長の文章を見た時「これは並々ならぬ意見があって、これを全部言うと大変だから一言に抑えるぞぉ」というものを感じました。 余談 経団連会長のところは実は私のところのようなマイクロカンパニーでもわかるところがあって、何かのチームに所属していてもバカバカしくなったらバッサリ辞めてしまいます。先月３月末で抜けたところもひとつありますが、５０年以上在籍した居場所だけに抜けるには１年間の根回しを要しました。本番は紙きれ一枚でしたが。それぞれ思い返しても若気の至りだなあとは思うところ多々あれど後悔はありません。 以前絵本を作っている出版社に「戦車が出ていて怖い」というクレームを入れられ差し替えたニュースがあったのですが。出版社からした
[予告] Dispenser の挙動を変えます。
非公式情報。まだ XMPIP は書いていません。コード修正先行の定常運転。 Ⓜ Dispenser を使いやすくするための Counterblock API を生やそうとしていたのですが、検討すればするほど「Dispenser 周りだけ Counterparty API や内部 DB の作りが宜しくない」感が強くなってきました。 ただし、ウォレット開発運用勢に余計な負荷を掛けないよう、互換性は可能な限り取ります。以下は、変更点概要。 Ⓜ まず、refill の廃止。同じアドレスに同じアセット(例えば XMP)の Dispenser を2回以上オープンしたとき、以前の残高を新しいコントラクトに継ぎ足してくれるという機能(refill)があります。便利なようでいて、残高の推移が DB から掴みづらくなる欠点があります。また、データがコントラクトに閉じなくなるので、設計として美しくありません。 変更後は、同じアドレス同じアセットの Dispenser を複数置けるようになります。 つまり、refill してくれると思って 1MONA→1000XMP を販売しているアドレスに 1MONA→1000XMP の Dispenser を置くと 1MONA→(1000+1000 == 2000)XMP の販売となり、損するようになります。 一方で、1MONA→1000XMP と 10MONA→100XMP の2種類の Dispenser を同じアドレスにおけるようになります。この例では 10MONA→((1000*10)+(100*1) == 10100)XMP です。このような大口購入者へのインセンティブを与えるには複数のアセットが必要でしたが、その制限が撤廃されます。 refill と同等のことをしたければ、一旦 close してから再度 open すれば叶います。 Ⓜ 次に Cancel メッセージが Dispenser をサポートします。これは、普通にモナパーティを使っている限りは気にならない、深い部分の話なのですが。たぶんウォレットを作っている人には少し影響があります。 Dispenser もモナパーティの組み込みコントラクトなので、識別は tx_hash で行えます。ならばコントラクトの取り下げは Cancel メッセージを経由するのが Counterparty の流儀に沿っています。現状のような close status を create するのは美しくありません。 しかし、create_dispenser API に破壊的変更を加えると既存のウォレットが軒並み動かなくなります。そこで、close status での create が飛んできた場合には
Monacard2.0計画
Monacardをアップデートして大きく仕組みを変えようと思います。ユーザー、開発者の意見によっては中止する可能性もあります。細かい仕様はMonapartyが更新されたのち動きを見ながら決定します。時期MonapartyがIPFSに対応したのち状況を見極めてからになります。 目的1. card.mona.jpが終了した場合にMonacardの情報が消失するリスクをなくす。2. IPFSへの画像アップロードを促し、画像が消失するリスクを減らす。 仕様card.mona.jpでのカード登録機能を廃止し、Monapartyアセットのいずれかの部分(Descriptionなど)に現在のMonacardに登録しているのと同じ情報をJSONとして書き込んでもらいます。imgurの部分だけはIPFSに関連する情報に変更になります。このJSONの形式をモナカードプロトコルと呼ぶことにします。しばらくはcard.mona.jpだけで十分かもしれませんが、モナカードプロトコルを参照するシステムはだれでも作ることができます。card.mona.jpの役割今まで通りエクスプローラーや保有カードの表示機能を維持します。APIはアセットのJSONから取得したものを今まで通り表示します。card.mona.jpは情報の橋渡しをするサイトになります。また、Monacard2.0で不便が生じた場合支援する機能を作成します。例えば、JSONを打つのは面倒ですので作成を支援するページなどを必要に応じて作成します。 互換性APIを使用しているサイトが何も対応しなくても問題が生じないように配慮したいと考えてます。今までのMonacardとMonacard2.0をラップする形でAPIが情報を提供します。現在imgur_urlのパラメーターで配信している部分にブラウザが直接参照できるURLを代わりに入力することを考えています。APIにはバージョン情報など新しいパラメーターが追加される可能性があります。登録機能に関してもしばらくは併存させる可能性があります。心配事imgurのように画像のサイズが自動で生成されないので、そこら辺をどうクリアすべきか考えています。Monacardの進捗LEVEL1: アセットと画像を結びつけることができるLEVEL2: Monacardで遊ぶユーザーがいるいまここ→LEVEL3: Monacard周辺のサービスが整うLEVEL4: Monacard2.0LEVEL5: 多くの日本のイラストレーターがMonacardの作成を検討するLEVEL6: 多くの世界のイラストレーターがMonacardの作成を検討する
