盘点四个Web3社交项目
Posted Web3_dreamer
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了盘点四个Web3社交项目相关的知识,希望对你有一定的参考价值。
Web3 成为近两年互联网圈的热门话题,被冠以「下一代互联网」的称号。Web3 社交赛道蓬勃发展,开始对中心化的 Web2 社交平台产生冲击。
Web2的各大社交平台垄断了用户数据,并因此获益。而基于区块链技术构建的 Web3 社交产品,将数据交还给用户并由用户授权第三方使用,同时数据的经济效益也将归属于用户。
从根本上讲,Web3 产品天然成为了 Meta(Facebbok)、推特等互联网社交巨头的“挑战者”。Web3 是技术发展推动下的必然趋势,时代洪流滚滚向前,Web2巨头们无法扼杀 Web3 社交的蓬勃发展。
本期,我们将盘点目前市场上主流的 Web3 社交产品。需要说明的是,目前 Web3 社交赛道并没有明确的划分标准,本文仅盘点具有代表性的项目。
BBS Network:去中心化版 Reddit
BBS Network 是一个类似于 Reddit 的去中心化社交网络,用户可以在其中创建论坛来发布、评论和分享想法,同时从内容中产生收入。任何用户都可以在该平台创建 BBS,每个 BBS 都可以在自己独特的域上运行,同时仍然链接到所有其他 BBS ,其中的创作者、策展人和利益相关者以自动和透明的方式获得项目的原生代币奖励。
在 BBS 上发布的每个帖子实际上都是 NFT,用户可以购买、出售甚至租赁,同时收集他们拥有的任何帖子产生的广告收入。在 BBS 上,帖子的影响力由实际市场力量决定,其创造的价值会在帖子的创建者、当前所有者和板块管理员之间共享,这会激励每个人尽力使 BBS 尽可能吸引观众和利益相关者。
每个 BBS 所有者都可以设置自己社区的审核规则和内容政策,用户可以自由选择访问和参与哪些板块以满足他们的需求。BBS 可以使用插件模块进行定制和增强,促进用户的选择和多样性。
BBS Network 可能面临的问题是:NFT 的价值验证需要靠浏览量、评论等数据,然而一个已经完全曝光的帖子又如何对广告主产生对应的价值呢?帖子被更多人看到意味着其在潜在购买者心中的意向价位越高,但也意味着更少的人能够被广告触达,这可能会使投资者与广告主之间错配。另外,如何能在不引起用户反感的情况下让广告触达已浏览 NFT 的用户?
Torum:去中心化Twitter
Torum 是基于 BSC 的一个专为 Web3 而设的社交平台,旨在为用户建立一个完整加密生态系统,支持 DeFi、NFT 以及社交功能。
社交是 Torum 的核心与基础,其社交界面类似于 twitter,用户可以进行发帖分享、浏览订阅及热门帖子、发表评论等活动。Torum 将加密用户的活动整合到社交板块中。在“companies”板块中可以看到入驻公司的业务动态,在“clans”板块可以加入各类不同主题的群组,“airdrop”板块提供空投信息及参与机会,“news”板块以聚合器的方式推送新闻,待推出的“torumgram”板块允许用户在torum上使用telegram,“lounge”板块则提供语音聊天服务。
Torum 最明显的问题是,其愿景太过宏大,功能众多,但各个板块之间要想产生协同效应较难,容易头重脚轻,最后可能导致众多功能逐渐沦为鸡肋。目前的情况是,出了社交之外的其他板块数据并不理想。此外,这些功能的开发、运营维护,也会加重了项目自身负担。
Mem Protocol:去中心化版「知乎」
Mem Protocol 旨在打造 Web 3.0 版本的“知乎”,让用户通过分享知识赚取收益。通过智能合约,Mem 用户可以在区块链上验证自己的身份,并建立自己的可验证的声誉体系。该协议还构建了一个界面来浏览链上钱包的链上数据,并设计一个开放协议来记录钱包和代币生成的交互和关系。
Mem 将网络参与者的信息——包括社交媒体历史、链上活动和专业经验——存储在加密的保险库中。该数据由用户拥有和控制,当用户允许时,这些数据可以作为“社会信用评分”或“社交图谱”。
通过使用声誉体系和智能合约,Mem用户可以使用他们的身份在区块链上进行那些在现实世界的动作,例如提出问题、为赏金筹集资金以及建立自己的可验证的、特定于场景的声誉体系。
Mem 希望使用社交代币和智能合约来促进建立基于该协议的应用程序和社区,例如产品评论、社交媒体和求职等广泛应用。
Mem Protocol 的问题是,其竞争对手遍布整个 Web2 网络,包括知识星球、得到、分答等等,并不具备特殊优势。链上数据凭证,在知识付费中能否成为核心竞争力目前还是一个未知数。
CyberLink:去中心化版「微信」
CyberLink 由来自新加坡的 CyberGames 创业团队打造,CyberGames 获得了 CyberHash 和投资人 Alex Zhu 的注资,它是基于 BSC 开发的一款 Web3 社交应用。用户可创建的 DID 身份作为个人标识,限量发售的赛博兔 NFT 还可参与丰富的 SocialFi 活动。需要指出的是 CyberLink 仅是开端,CyberGames 团队旨在打造元宇宙平台 CyberWorld ,构建一个面向未来的虚拟世界。
CyberLink 采用点对点加密技术以解决隐私问题,为用户提供聊天、话题、交易、俱乐部等基础功能。此外, DeFi 和 CyberDAO 也将作为主要探索方向。目前, CyberGames 团队已推出 Cyber Space Protocol 并正在研发 CyberUP Protocol ,其长期使命是建立用户的社交图谱,与不同的协议集成,成为 Web3 社交基础设施的一站式解决方案。
CyberLink 的问题是,如何从 Web2 社交巨头的优势中脱颖而出。CyberLink 需要为用户提供在 Web2 中所习惯的 UI/UX 等效的用户界面/用户体验,然后才能显现出自己的新优势,例如社区所有权、去中心化、可组合性和无需许可构建。
总结:Web3社交成为下一风口
Web3 社交平台正在开启一个新时代。浪潮滚滚向前,传统巨头纷纷下场。
Meta、TWitter、Google 等巨头都发现了想要取代自己的创业公司,并且积极拥抱 Web3。互联网巨头们在强烈的危机意识下,催生出同样强烈的创新意识。谷歌、苹果这样的巨头都投入了巨大资金对未来技术进行研究;推特宣布推出新功能,将拥有 NFT 的用户头像显示为六边形;Meta、Youtube、Reddit、Google 都宣布尝试推出 NFT 产品,加入 Web3 产品的研发中。
目前加密市场原生的 Web3 产品,虽然有着一定的先发优势,但仍然有很大的进步空间。当巨头们涌入时,留给前者的生存空间势必越来越小。狭路相逢勇者胜,这一场好戏才刚刚拉开序幕。
盘点2016年的移动 Web 发展
本文为《程序员》2016年12月期原创文章,未经允许请勿转载,更多精彩文章请订阅2017年《程序员》。
在即将过去一年,我经历了两个项目:一个是基于 React 与响应式设计的房地产搜索网站;一个则是基于 Angular.js 与 Ionic 1 的金融混合应用。而这两个不同的项目,正好可以代表移动 Web 的两个方向。在这一年里,一些前端框架已经趋于稳定,我们可以看到诸如 React 这样的框架在一些大型项目中的采用。除了这些常规的移动 Web 应用,在今年九月底微信小程序的火热,也开启了移动 Web 的一扇新门;Google 推出的 PWA 也让越来越多的开发者看到了移动 Web 的更多可能性。
面临的问题及考验
尽管网络速度正在变得越来越快,但是移动 Web 页面的体积也越来越大。单页面应用的体积在首次加载时,仍然值得我们好好研究——如何更快展示用户需要的内容,而不是让用户在页面加载的过程中等待着让他们离开。除了使用服务端渲染来优化初次体验,我们还需要设置缓存,使用一些技术策略来加快用户打开的速度。
然而,我们仍然还面临着一堆亟需解决的问题。比如在服务端采用微服务架构来加速开发,当我们需要在一个页面里请求大量 API 时,微服务架构就会成为一个新的问题。当用户在请求过程中切换页面时,就需要中断大量 Promise 请求。因此就需要使用 GraphQL 或 Falcor 这样的 API 框架来减少客户端 API 请求。
➤安全
除去上面这些内部因素,移动 Web 应用还饱受外部因素困扰。在2016年,我们发现越来越多的移动站点正深受运营商劫持的影响,由于 HTTP 协议是明文的,而流量都要经过运营商,因此运营商可以轻而易举地在页面中植入广告。这时,解决问题的有效办法就是全站 HTTPS。与此同时,对于安全的考虑也仍然值得注意。我们意外地发现一些移动 Web 网站只在前台做了数据校验,而缺少后台的数据检验,这会带来相当大的安全隐患。
➤臃肿的前端代码
前端项目正在变得越来越臃肿,体积让人难以接受。在缺乏单元测试的项目里,维护这样的一个前端项目正在变得举步维艰。当后台走向微服务的同时,前端走向微前端也变得可以接受。一个应用程序可将基本需求分解为不同的几个前端页面,如面向用户、面向管理员。
尽管已经有了如 React 这样的 CSS in JS 的框架,维护 UI 组件仍然是一个相当大的考验。移动 Web 对于屏幕大小有更高的要求,响应式设计会带来更多代码。样式代码数量的增加,对于前端的样式架构有了更大挑战。如我们所见 SCSS 或 SASS 这样的 CSS 预编译器可以带来更少的代码,而对于项目中的新人来说,仍然是个问题——在项目进行过程中,我们往往关注于如何更快地交付功能。
相似地,我们也可以在社区开发的开源库上看到一些“微前端”趋势。借助于 ES6 的模块化功能,我们可以在项目中只 import 所需的函数,在使用 webpack 打包的过程中也会删去那些不需要的模块。过去我们使用一个库的某个方法时,可能就会考虑直接创建一个类似的库,而不是引入——原因是这个库对于应用来说太大了。
框架及工具
从传统 Web 网站到单页面应用迁移的第一个难题是:是否真的需要单页面应用?单页面应用更多的是带来用户体验的提升,然而很多网站并不需要这种变化,大部分网站只需要支持更好的响应式设计。
在上一个项目里,我们使用了 React 来替换之前的桌面及移动站点。除了代码老旧之外,还有部分原因:业务变更时需要修改三份代码。旧有的旧面网站代码可以追溯到2010以前,难以维护;移动站点是在2013年底创建的,使用当时流行的 Backbone + Mustache + Require.js 技术栈;与此同时还有手机 App。
当我们决定做一个移动单页面应用时,就需要开发考虑对于技术方案的选择。
➤框架选型
而在这一年里,开发人员在做技术选型时,发生了一些有趣的变化。首先是 React 对于大部分的开发人员来说,存在学习曲线比较陡峭的问题,JSX、虚拟 DOM、组件化、同构等,使其无法成为短期项目的首选;其次是 Angular 2.0 的跳崖性升级,使得相当多的开发人员无法选择 Angular.js 1.x 的版本,而2.0在接近年底才完成,且周边的组件还有待完善;因此,我们发现 Vue.js 由于其简单并且容易上手,在今年显得特别受欢迎。
幸运的是:上述三个框架,都有对于混合应用的应对方案。这使得我们在设计系统架构的时候,更容易复用代码。
2016年里,在移动和桌面 Web 使用 Angular.js,移动端使用基于 Angular.js 的 Ionic 框架是非常不错的技术选型。Ionic 拥有相当多设计优美的 UI 组件,这些组件可以让我们轻轻松松地做出移动应用。并且,我们也可以和 Web 端共用 filter、directives、services 等的内容。相信在2017年,Angular 2.0 搭配基于 Angular 2.0 的 Ionic 仍然是好选择。
我们也可以使用 React 框架来做类似的事。尽管有相当多的开发者选择使用了 React Native,但是这不意味着我们需要在移动端使用它。在移动端使用 Cordova + React 也是一个不错的选择——既然可以使用 React 做响应式设计来匹配不同的屏幕大小,那么也可以很轻松地使用 Cordova + React 来达到同样的目的。
同理于 Vue.js,尽管 Weex 还不是很成熟,但是使用 Cordova + Vue.js 也仍然不错。
➤开发工具越来越完善
在这一年里,我们发现能选择的开发工具越来越多。不同的开发商都在不断创造开发工具,这些工具可以帮助我们编写出更好的代码,开发出符合用户需求的软件。
现在市面上的主流前端开发工具都已经可以支持 ES6、TypeScript,并且不同的浏览器对于 ES6 的支持力度也在提高,Edge、Firefox、Chrome 对于 ES6 特性的支持度均在90%以上,而 Safari 浏览器则达到了100%。这也意味着对于面向 iOS 的移动 Web 应用,可以很随意地在这些设备上使用 ES6 语言了。
并且各浏览器对于移动设备的调试能力都在不断提高。在开发移动 Web 页面时,我们使用 Chrome 浏览器来匹配移动设备。而在新版本的 Safari 里也提供了“进入响应式设计模式”的功能,它可以模拟常见 iPad、iPhone 显示网页,甚至可以模拟 iPhone 横屏。
Adobe 在今年推出了 UX 工具 Experience Design(官方缩写XD),可以为 UX 设计师快速创建出用于移动设备的网站或者应用程序。这个工具除了具备响应式设计能力,还可以实现简单的 App Demo,如在桌面上点击某个页面跳转,并具备有页面间跳转的效果。这可以让开发者更容易理解产品的设计原型,创建出更符合需求的产品。
提供更好的用户体验
对于在早期已经采用单页面应用的团队来说,他们面临的一项新挑战是:如何提供更好的用户体验。
➤更好的用户交互
相当有意思的一点是,我们发现业务人员对于移动 Web 的要求更高了,他们希望有着类似于移动应用的用户体验。过去,在移动 Web 领域使用 Tap 事件来代替 Click 事件只是一个开始——使用 FastClick 这样的库来规避 Click 事件的延迟。
手势交互: 下拉时刷新在移动 Web 上已经不是新鲜的事,我们还要类似于微信的左右滑动切换不同的页面,除此还会有旋转、缩放等功能。
适配屏幕大小: 对于移动设备来说,屏幕是个大问题,应用既要支持 iPhone 这样的小屏幕,还要匹配上 iPad 这样的设备。可以使用媒体查询来解决,但设置合适的字体还是问题。px、em 已经很难满足要求了,我们还需要 rem 这样可以根据网页的根元素来设置字体大小的单位。
➤更流畅的体验
过去,我们关注的移动 Web 流畅度主要集中于缓存。当缓存已经成为了业界的通用模式时,人们便开始寻求更多的解决方案。如对于流量来自 Google 的网站来说,他们可以使用 Accelerated Mobile Pages(AMP)技术来加快网页的加载,这可以为新闻和博客网站带来更快的访问速度。
与桌面相比,移动 Web 页面对流畅度有着更高的要求,这主要是受限于移动设备。尽管新 iPhone 提供了相当快的处理能力,各大 Android 设备生产商在竞争中也在不断提高设备的处理能力,但是仍然有相当多的用户使用旧版移动设备。
在移动网页上,除了采用支持 Virtual DOM 的框架来提高性能,还可以采用 Virtual Scroll 机制——只渲染足够填充 Viewport 大小的数据集,页面滚动时再渲染新数据,以此改善移动端列表页面数据过多的问题。
除了对于页面本身的优化,还有相当多的内容是对于资源和 API 优化。Facebook 创建了 GraphQL 来减少 API 的请求,一次请求多个需要的 API;Netflix 创建了 Falcor 来合并多个数据源。这些都可以加快移动应用的响应速度,除此我们还注意到 Service worker 开始受到开发者追棒。
Service worker 是在 Web 应用和浏览器与网络之间的代理服务器,旨在创建更好的离线体验。并且可以依据当前网络是否可用、服务器是否有内容更新来采取合适的策略。同时它还支持通知推送及后台 API。
2017年移动 Web 展望
在这一年里,我们也看到了一些新东西正在展露头角,Google 推出了 Progressive Web Apps(PWA),微信也推出了小程序。
➤微信小程序
如微信小程序官方介绍所说:
微信小程序是一种全新的连接用户与服务的方式,它可以在微信内被便捷地获取和传播,同时具有出色的使用体验。
用户只需要在微信客户端下载相应的小程序,就可以直接使用,用完即可离开。由于微信本身的封闭属性,小程序的运营和推广上仍然会有相当多的难点,同时也造成了一些传播上的难题。
不过微信自带了 WebView,开发者在开发时只需要针对不同操作系统的设备开发软件即可,不容易再遇到不同版本上的浏览器差异。同时微信小程序使用自己的 Web 框架,开发者需要重新上手这个框架,由于小程序还处于测试版,仍然还有相当多的 Bug。
➤PWA
PWA 是 Google 在 Google I/O 2016 大会上强调的移动 Web 应用程序方向,我们可以翻译为“渐进式应用”。它结合了 Web 和原生应用程序的优势,提供了更好的用户体验:
应用程序不需要安装;
不依赖网络连接,可以支持离线使用;
提供类原生应用的体验;
自带响应式用户界面;
持续更新,通过 Service worker 让应用程序保持在最新的状态;
可安装在桌面等。
它为开发混合应用的开发者提供了一个新方向,虽然受限于国内 Chrome 普及率,但是我们仍然很看好这项技术。
在这一年里,我们也看到了 Google 正在推进 Web NFC API、Web Bluetooth API、Web USB API 等原生 API 的发展。现在,已经可以在 Chrome 浏览器上通过编写 JavaScript 来开发蓝牙应用,这也使得 PWA 可以制作出更富有质量的移动 Web 应用。
作者简介: 黄峰达,ThoughtWorks 软件开发工程师,CSDN 博客专家。长期活跃于 GitHub,专注于物联网和前端领域。出版著作《自己动手设计物联网》,以及《Growth:全栈增长工程师指南》等六本电子书,并译有《物联网实战指南》。
技术之路,共同进步,欢迎投稿、约稿、给文章纠错,请发送邮件至mobile@csdn.net。
以上是关于盘点四个Web3社交项目的主要内容,如果未能解决你的问题,请参考以下文章