2019首发,IPFS动态更新-24

  • 0_1547025107121_a72e122e-0151-4c48-89a6-61f32849b3ec-image.png

    欢迎观看2019年首次IPFS周报!🎉

    在2019年回来工作的第一周,我们回顾了2018年星际文件系统(IPFS)社区所做的事情,同时进行了一次特殊总结。

    --

    2018年 重要里程碑的一年

    --
    1月:Mozilla 在火狐浏览器中增加了对分布式协议的支持。

    2月:libp2p引入全世界,这是一个使用ipfs模块化构建的点对点网络堆栈。

    3月:js-ipfs v0.28.0发布,Juan Benet向麻省理工学院最大的研究实验室,计算机科学与人工智能实验室提交了新的网络分类;go-ipfs发布了0.4.14版本。

    4月:我们介绍了IPFS Companion 2.2.0,并让大家了解了Windows上的go-ipfs。

    5月:我们首次宣布了IPFSConf,Textile推出的一款可在移动设备上运行,实现真正分散存储的个人IPFS;js-ipfs 0.29.0发布,我们通过在新推出的IPFS群集网站上,启动IPFS群集0.4.0候选版本。

    7月:GitHub上的Awesome IPFS工具作为一个网站重启动;连续发布了JS IPFS v0.30.0 和 v0.31.0版本;JS-libp2p第一次正式发布,最后go ipfs 发布了 v0.4.17版本。

    8月:我们在加州旧金山庆祝了2018实验室日,同时发布了星际关联数据(IPLD)explore网站和 js-ipfs:js.ipfs.io官方网站;IPFS Cluster 0.5.0版本发布。

    9月:Cloudflare发布了他们的IPFS网关,以及IPFS周报回归;js-ipfs 0.32.0版本发布,紧接着ipld-explorer-cli 0.14版本也进行了发布。

    10月:IPFS Pinbot在Twitter上出现。

    11月:进行发布的重要月份!

    js-ipfs 0.33、go-ipfs 0.4.18 和 js-libp2p v0.24.0 进行了发布。

    12月:我们在2018年结束时进行了一些组织工作,重新命名了HTTP客户端库。


    0_1547025281762_cdf1947e-d216-4e8c-8160-622158f13584-image.png

    非常棒的新闻

    --
    主要出版网站发布了我们的一些里程碑事件,所以在这里回顾一下与我们有关的一些新闻。

    8月:Mozilla Hacks网站 发表《Dweb:利用IPFS建立合作和信任的网络》

    9月:卫报 发表《权力下放:万维网的下一个重要步骤》

    10月:麻省理工学院技术评论 发表《从大型科技公司中解放互联网的科技公司》

    11月

    福布斯杂志 发表《可以分散影响并增强地理位置数据隐私吗?》

    Nasdaq网站 发表《泰国在Primaries 使用区块链支持的电子投票系统》

    Hackernoon 发表《打破僵局:IPFS、以太坊和Fat 协议的速成课程》


    0_1547025344796_3b3940d1-abfd-433b-a185-9207db644aac-image.png

    全球社区活动

    --
    在这一年中,人们很高兴了解和谈论IPFS。以下是我们彼此见证的一些事件,如果你错过了,在2019年还有机会参与!

    1月:IPFS里斯本活动,2018年是分布式网络的一年🌐🌐。

    2月:WebVR / AR III研讨会:俄勒冈州波特兰市的混合现实网络。

    5月:巴尔的摩/ DC 举行了一次IPFS会议。

    8月:IPFS社区参加了2018年在加利福尼亚州旧金山举行的分散式网络峰会。

    10月:第一IPFS柏林聚会和IPFS展览及在伦敦告诉发生。


    特别说明:2018年在IPFS项目中,共有261位贡献者,在167个存储库中提交了8417次。通过这些贡献者的帮助,2018年IPFS是令人惊叹的一年。

    ❤️非常感谢你们所有人的时间、专业知识和贡献,没有你们每个人我们都做不到。



    0_1547025431137_4d1900fe-ad90-444a-9e7a-21c08da2280f-image.png

    使用Awesome IPFS构建网络

    --
    这些只是在Awesome IPFS网站提交的一些新的应用程序和工具,通过这些表明了人们对使用IPFS构建内容感到兴奋。

    • brig - 使用git接口和FUSE文件系统进行文件同步。

    • IPFSStore - 使用Steem支付固定费用

    • Autonomica“IPFS社交证明” - Autonomica是一个类似Keybase的Dapp,用于通过已发布的社交媒体和网络证明,创建身份并证明此身份。

    • TallyLab - 本地优先的端到端加密日记应用程序,用于捕获、分析和共享有关任何内容的数据。

    • Pinata - 通过Pinata的REST API和IPFS工具包构建和管理您的dapp。

    • enzypt.io - 通过以太坊和IPFS购买和出售文件的网站。

    • qri - 分布式Web上的数据集创建、协作和发现。

    • Peer Bandwidth Demo - 使用window.ipfs的演示应用程序,由IPFS Companion Web扩展提供,用于获取和绘制IPFS节点的带宽信息

    • killcord - 一个抵制审查的deadman’s开关

    • Philes - 一个简单基于浏览器的IPFS记事本应用程序。

    • Arpadyne - 新的互联网,由OrbitDB提供支持的DNS,通过IPFS提供的内容。

    --

    ☺️感谢阅读!


    识别二维码进入IPFS社群

    0_1547025528850_b9571e84-5f1f-403b-b47f-ff871b1baa98-image.png

Log in to reply
 

Email:filapp@protonmail.com

Twitter:

https://twitter.com/RalapXStartUp

Telegram:

https://t.me/bigdog403

全球Filecoin中文爱好者网站

  • X

    It has come to my attention that storage clients wish to obtain the CommD and CommR associated with the sector into which the piece referenced in their storage deal has been sealed. The client can already use the query-deal command to obtain the CID of the commitSector message corresponding to that sector - but message wait doesn't show individual commitSector arguments - it just shows some string encoding of the concatenated arguments' bytes.
    I propose to augment the ProofInfo struct with CommR and CommD such that the storage client can query for their deal and, when available, see the replica and data commitments in the query-storage-deal command. Alternatively, the query-storage-deal code could get deal state from the miner and use the CommitmentMessage CID to look up CommR and CommD (on chain) - but this seems like more work than is really necessary.

    阅读更多
  • X

    Hmmmm. These are just my thoughts off the cuff:

    For straight-ahead performance that's not specifically concerned with the issue of loading the data (from wherever), then work on smaller (1GiB) sectors is okay. When considering optimization for space so that large sectors can be replicated, 128GB for >1GiB sectors is obviously problematic from a normal replication perspective. However, if we consider the attacker who wants to replicate fast at any cost, then maybe it's okay.
    Based on this, we could probably focus on smaller sectors as a reasonable representation of the problem. This has the unfortunate consequence that the work is less applicable to the related problem of speeding replication even when memory must be conserved to some extent.
    I guess as a single datum to help calibrate our understanding of how R2 scales, it would be worth knowing exactly how much RAM is required for both 1GiB and (I guess) 2GiB. If the latter really fails with 128GB RAM, how much does it require not to? If the work you're already doing makes it easy to get this information, it might help us reason through this. I don't think you should spend much time or go out of your way to perform this investigation though, otherwise.
    Others may feel differently about any of this.

    阅读更多
  • X

    @xiedapao
    If there does exist such a thing, I cannot find it.

    zenground0 [7 hours ago]
    I don't believe there is

    zenground0 [7 hours ago]
    tho maybe phritz has some "refactor the vm" issues that are relevant

    laser [7 hours ago]
    I assert to you that we must create an InitActor in order for CreateStorageMiner conform to the specification.

    Why [7 hours ago]
    I’ll take things I don’t disagree with for $400 Alex

    zenground0 [7 hours ago]
    Agreement all around. However this is one of those changes that is pretty orthogonal to getting the storage protocol to work and something we can already do. We need to track it but I see it as a secondary priority to (for example) getting faults or arbitrating deals working.

    anorth [3 hours ago]
    Thanks @zenground0, I concur. Init actor is in our high-level backlog, but I'm not surprised there's no issue yet. Is it reasonable to draw our boundary there for now?

    阅读更多
  • X

    Does there already exist a story which addresses the need to create an InitActor?

    阅读更多

Looks like your connection to Filecoin.cn中国爱好者社区 was lost, please wait while we try to reconnect.