IPFS最新动态-26

  • 0_1548658062761_8074e2b2-d2fa-48c3-bd69-2eb9fad7b40c-image.png


    星际文件系统IPFS)是一种新的超媒体分发协议,通过内容和身份进行寻址。IPFS支持创建完全分布式应用程序,它的目的是使网络更快、更安全、更开放。

    由于这是一个相当大的范围,我们会跟进整个生态系统的开发,并在每周进行发布。


    最新资讯

    --


    认识 Matt Ober😸

    --
    马特·奥伯(Matt Ober),来自内布拉斯加州的奥马哈(Omaha),他大部分时间都在奥马哈编写Pinata的所有代码。Pinata是IPFS生态系统的固定服务,通过各种工具和API端点,可以轻松管理IPFS上的内容。Matt在开发Pinata的空闲时间,通常会和他的狗Winston一起出去玩,或者尝试做一些他在网上找到的各种晚餐食谱。


    相关文章

    --
    以下是最近一周发表,与IPFS有关的文章

    • 《区块链技术如何帮助大麻在自然灾害中的恢复》,2019年1月21日,发表于Forbes

    • 《Torrent Paradise通过IPFS创建分布式的”海盗湾“》,2019年1月20日,发表于Torrent Freak

    • 《建立世界上第一个IPFS数据中心 - 第1部分》,2019年1月18日发表

    • 《IPFS与HTTP:分布式网络如何使互联网再次发展》,2019年1月11日,发表于Crypto Insider

    • 《在Ubuntu上部署私有IPFS网络的5个步骤》,2019年1月11日发表

    • 埃及公司Elkrem在CES2018展出其顶尖技术,2019年1月10日

    0_1548658295654_66ced06a-e93b-4405-8b56-be18312d3c25-image.png


    版本更新

    --
    查看整个生态系统中最新版本的IPFS工具和项目。

    • IPFS Cluster 0.8.0 版本发布!

    • Textile Photos 0.5.0 版本发布

    • IPFS桌面客户端:Orion v1.0 版本发布

    • OneLoveDTube IPFS 0.8.3 版本发布:移动优化、多分辨率上传支持等!


    IPFS工具与项目

    --
    Awesome IPFS 是一个用于社区维护和更新的项目、工具清单,任何与IPFS相关的东西都能够在其中找到。如果想要查找相关信息,可以访问GitHub上的Awesome IPFS,然后将要查到的内容添加到搜索列表中。

    • 有人在IPFS上创建了一个Udemy课程!

    • 2read - 将当前标签中的文章转换为可读形式,并将其上传到P2P网络(IPFS)。

    • Haven - 是ob1的一个新应用,允许用户私下聊天、购物和发送加密。

    • PirlTube WebView 测试版发布!通过浏览器访问PirlTube上共享的不可变分布式视频内容!最分散的视频共享平台没有SPF,完全托管在Pirl基础设施上

    • Nile - 是一个分散的、免佣金、以地方经济为中心的在线购物平台。


    社区活动

    --
    IPFS在discuss.ipfs.io上有一个论坛,注册之后可以看到IPFS在上面发布的公告,同时能够了解到社区即将举行的交流活动。

    --

    ☺️感谢阅读!


    识别二维码进入IPFS社群/矿机群

    --
    ![0_1548658543494_8152f84c-dc9e-4eff-b31d-9da87d9cdb20-image.png](正在上传 100%) 0_1548658484430_316ca0e5-8fb2-43d3-a078-e2b7f5a24734-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.