推了一个很靠谱的朋友过来 晚点联系你 😃

@japeth 暂时不需要了，前后端基本已经完成了，没有什么开发需求，小需求我们自己也能处理

@Clannad0708
@honkew 感谢支持 ai 领域可以创业的方向还挺多的，我们做得太晚了，做的早的已经开始分羹了😃
比如之前发现某美国华人做的一个图片处理平台，质量跟开源的基本没有差别，而且网站代码质量写的实习生都会鄙视那种（还存在权限 bug ），但是别人做的早流量挺不错，毛估月收入几千刀+

我们的访客注册率接近 40%，说明这一块市场需求是不错的，目前的短板就是产品效果了

@bjzhush 很难 openai 的尝试都没有成功 误判率较高
而且随着 ai 升级，以后检测会越来越难，ai 能像 sd 一样完全模仿某类风格，对人来说几乎没有区别

@LeeReamond 不会,app 只是方便普通用户使用,但技术圈肯定会对数据做校验的,app 层没法作弊,因为算法都是开源的
就像区块链钱包一样,你可以用官方钱包,可以用开源钱包甚至可以直接网页钱包,只是方便普通人使用,但你要是敢乱来,只要一次产品就死了

@8520ccc 多随机因子只适用于黑盒中运行的系统（例如 linux 的熵池，相对黑客它是不可见的）
对于抽奖这种需要公开的模式，反而更危险，因子越多被攻击可能性越大，因为只要有任何一个点被成功攻击，其他的都形同虚设

@hanxl 对 图文是最麻烦的,每个平台规则不同, 就连 markdown 都不一定保证兼容,需要针对性微调
当然这不是最麻烦的,最麻烦的是平台还经常更新....所以要不断维护,作为非盈利性开源项目想兼容恐怕难

@moioooo 区块链没法创造随机数,所以很容易被攻击
参考合约用 hash 开奖的,经常都有被攻击的新闻,这还是暴露出来的,没有暴露的不知道有多少

@LeeReamond 这个只是技术上麻烦,但是算法应当公开,通过应用或 app 封装整套流程,对普通用户来说跟普通抽奖没有区别,而有技术的团队也可以验证和监督该过程

总和哈希并不安全,有些区块链抽奖就用的这个方式,已经有多起攻击案例

目前我了解最为安全的应该是"承诺"的方式
例如随便想个简单模式,之前在知乎也回答过

用户 a 选择了一个号码比如 784516 ，再自己创建一个随机数例如 32 位的 de90fcea....，再将号码和当期期号和随机数一起进行 sha256 计算指纹，然后你将指纹提交给彩票中心购买该指纹的所有权，这样彩票中心只知道你的指纹没法知道你的号码。

开奖就简单了，开奖后彩票中心通知中奖号码是 784517 ，购买过彩票的用户都开始上传自己的原始信息-彩票号码、期号、随机数，(sha256 的计算复杂性也保证了用户没办法现场计算一个虚假的信息来冒充中奖信息-超算都没法)，彩票中心收到信息之后告知你的号码只错了一位得了一等奖。

有没有漏洞? 还是存在的,中心可以进行自我攻击创建多个中奖号码,但至少解决了中心知晓每个号码的问题-这样对平台来说没办法修改中奖率了,如果彩票敢这样玩,我也敢每期买.

要想彻底防范感觉还是引入三方随机数生成,或者基于多个可信分布式秘钥(或类似门限签名)来组合生成最终中奖结果,空了我再想想

另外你们的 github 地址太隐蔽了,用户想点 star 都要找半天

自媒体领域分发软件倒是挺多的 蚁小二 易媒之类的估计有几十种
不过公开的不一定有你想要的这几个,有实力的团队有可能是自研,比如我们之前就是自研分发,文章 图文 视频,还有很多选项各个平台都要做兼容,chrome 后台静默发送

看着很牛逼,先关注下
不过比起成熟类库优势这么大还是有点怀疑,最好能开个文档说明一下优势来自哪里
我简单测试了下,内存和速度确实挺快,再测了下 1w 正方形物体移动,只加了个
setInterval(() => {
group.position.y+=0.01
},10)
相比起来 pixi 的 cpu 和 gpu 占用均只有 leaferjs 的一半左右, 所有在实际环境中表现如何还有待测试

另外 runapi 客户端颜色搭配还有点乱，虽然走的简约路线但是很多版块感觉糅杂在一起不容易区分，建议优化

能不能加个手动关闭更新提示功能

国内的安卓一言难尽,之前用小米的,把应用锁定后台不释放,仍然一样的,最夸张的时候切换回桌面就 kill 了-哪怕加了锁

我的是 dropbox 停止了几乎 1 年了,4 月突然发现本地直接给我清空了,线上也没有了,回收站也找过莫名消失,账号通过 google 登录不考虑被黑,没有做过其他任何更改,很奇怪...
不过早就迁移了重要文件了倒无所谓

建议中间插个交换机试试是否正常(直连本机和 pve) 尽量排除干扰因素