> This is more than minimum Ethereum node requirements
Oh, come on. Ethereum's base layer handles less than 30 transactions per second. If this was unbounded of course it would require more hardware as well...
> This is more than minimum Ethereum node requirements
Oh, come on. Ethereum's base layer handles less than 30 transactions per second. If this was unbounded of course it would require more hardware as well...
There is something *deeply* broken with Fedi culture when the admin of the third largest Mastodon instance needs to run a panhandle in order to make rent.
Link, please?
Ok, I can only see the link (https://codeberg.org/fortified/forte) if I visit your page. For some reason Mastodon did not put the link in the message.
Do you mean that it hasn't been tempered by the server admin? No. The keys are managed by the server. So a malicious admin could generate messages on behalf of the user.
But assume that your server receives a random message. It is properly signed and you can verify the actor. How can you guarantee that the message was sent by the user and not the admin?
Big Tech defende os interesses deles e de seus investidores "e água é molhada"...
Jornalista publica algo fingindo isenção "e água é molhada"...
> JSON-LD processing doesn't seem to solve any problem developers face in the real world
To me, it's the opposite. Without JSON-LD, my application needs to have a bunch of parsing/serializing code in order to talk with everyone else. With JSON-LD, we could just rely on any RDF library and get the data structures that we need right away.
By avoiding JSON-LD, you end up dealing with *more* complexity, not less.
What programming language are you using? Pretty much any RDF library can parse JSON-LD.
I'm getting really closed to get nerd-sniped by this and set up a database viewer to see who-is-following-who on the server. :)
@scott but shouldn't it be possible for Hubzilla to track who-follows-what, and only send the messages accordingly?
I surely don't follow you from your other identities. Maybe Hubzilla could have a system that sends messages only with as:Public by default, and only addresses the responder with the "in reply to" field by the follower's known aliases?
> As such, Mastodon does not realize that all of those are the same channel and the same post.
I'm usually quick to point fingers at Mastodon, but I'm not sure if this time they are at fault.
Mastodon (and most of ActivityPub current server software) does push-based interop. This means that any notification that I receive corresponds to one different activity being POST'ed to my actor inbox.
I'm not familiar with ZOT, but I'd be curious to know what is causing this.
Yeah, you definitely need to synthesize some type of benchmark. There is no other way to answer the question "what do you think of this pricing strategy?" if you have no idea about your costs.
If you'd like to have some kind of load test, maybe you could set up an instance that mirrors 100k random active Instagram accounts and see what happens both with your instance and the network?
FYI: each reply from you is generating multiple repeated responses, (presumably) one for each identity you have set up?
I think the key question I'd have is the one you are still figuring out the answer: given a deployment of a hubzilla server with a configuration, how many users can you serve it?
E.g, how small is the $6/month "small instance"? Can it work with 10 users? 100? 3? And what happens when the average user follows 100 other people on the Fediverse? And what happens if one of these users follows a bunch of media heavy content? What would happen if one popular user is followed by 2M people?
So: 10k paying customers. Assuming $50/year/customer, that's $500k in yearly revenue. What about operating costs? Surely serving 1m users will require a good amount of servers/bandwidth/storage/backup?
@scott how many paying members are you expecting to get at this price point?
It doesn't do any type of personal data collection yet (aside from the questions you are answering).
My overall plan to deal with account management is to implement oauth on the main application, so that people can "login" to the site simply by proving ownership of their activitypub handle, and from there they would be able edit/extend/delete their profile.
Just follow the cupid actor and your account is automatically created.
It's done already: https://cupid.careers lets you follow @thecupid and get job listings and polls that are used to figure out other potential co-workers...
Creator of communick.com. #fedi22 #opensource #decentralization
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.