3 ms·

Well part of that effort is that I'm working on a standard protocol for communication. But I don't think the protocol alone is the answer. It's definitely part

by asim 3y ago

Well part of that effort is that I'm working on a standard protocol for communication. But I don't think the protocol alone is the answer. It's definitely part of the solution but you need to actually build the rest of the solution too. https://mu.xyz/network#protocol https://mu.xyz/network#protocol

theshrike79 3y ago
[insert xkcd comic about standards] We already have ActivityPub, no point in trying to reinvent the wheel without a critical mass of users and services. Mastodon + Lemmy + Pixelfed are built on ActivityPub, what does your protocol bring to the table?
- asim 3y ago
  Well I guess I've spent two decades in software, networks and distributed systems engineering, especially quite significantly in protocols and platforms. It's not that I want to create some new protocol, it's that there's a certain inadequacy in the existing ones for service to service communication e.g http was made for hypertext transfer, its for web pages. More modern protocols like gRPC have tried to do this thing but as rpc with a binary protocol that is largely obtuse and has not shown itself to be more widely adopted as a standard for open services. I think ActivityPub is specifically geared around social communication whereas I'm thinking more like the services layer or what we currently do in random ad-hoc ways as HTTP APIs. For me, the protocol is about creating something very standard for API services that are human readable and can exist alongside SMTP and HTTP. Again, didn't set out to create yet another protocol, I'm just not seeing great standards around services.
  - rgbrenner 3y ago
    Personally, I think its great to think about protocols and the tech that goes into it... but only because its interesting to me technically. Some of this kind of sounds like: I have a cool protocol and now Im in search of a problem that I can apply it to. What app should I duplicate first? You need to flip this around and ask: what kind of service can I build that would deliver new or additional value to users, that is a significant enough improvement that users will switch en mass. Then go do that, get a bunch of users, and then release your protocol and encourage others to participate. There's nothing wrong with doing it all in parallel, but the primary problem -- getting users -- is large enough to consume all of your energy. EDIT: Or become a protocol evangelist... write your protocol, document it well, and start advocating it and explaining the advantages... maybe you can get Lemmy and other platforms to adopt it instead of ActivityPub. You can also write up patches to add support for it to various open source projects. Let them worry about building the remaining parts of solving the social problem... there's definitely room for multiple groups to work on solving this problem together.
  - syntheweave 3y ago
    Well, to come up with the applications, you just have to go back to the original rationale to use computers: to automate the generation of some kind of answer to a question. The automation should be either equal to or higher quality than a manual alternative, or so much faster and cheaper that lower quality is acceptable. When we look at that in terms of service interfaces, it's an attempt to black-box some part of answer generation, to say "this other party will do that"...which means that it's orthogonal to the answer itself. The most direct way to get good answers would be to already know them, and everything else, like the question you ask of an interface, is secondary. Interfaces tend to be a point of friction to accessing answers because they have to assume in some sense that you know what you want to ask and how you want to phrase it. If you got the right answer from asking the wrong question you'd be extremely pleased but also confused. So it helps to establish concretely what kinds of questions are asked for each application, and turn those into interface specs. That's where a lot of the design challenge is - capturing the question/answer cycle succinctly, without overgeneralizing.

by asim 3y ago

theshrike79 3y ago

[insert xkcd comic about standards] We already have ActivityPub, no point in trying to reinvent the wheel without a critical mass of users and services. Mastodon + Lemmy + Pixelfed are built on ActivityPub, what does your protocol bring to the table?

asim 3y ago
Well I guess I've spent two decades in software, networks and distributed systems engineering, especially quite significantly in protocols and platforms. It's not that I want to create some new protocol, it's that there's a certain inadequacy in the existing ones for service to service communication e.g http was made for hypertext transfer, its for web pages. More modern protocols like gRPC have tried to do this thing but as rpc with a binary protocol that is largely obtuse and has not shown itself to be more widely adopted as a standard for open services. I think ActivityPub is specifically geared around social communication whereas I'm thinking more like the services layer or what we currently do in random ad-hoc ways as HTTP APIs. For me, the protocol is about creating something very standard for API services that are human readable and can exist alongside SMTP and HTTP. Again, didn't set out to create yet another protocol, I'm just not seeing great standards around services.
- rgbrenner 3y ago
  Personally, I think its great to think about protocols and the tech that goes into it... but only because its interesting to me technically. Some of this kind of sounds like: I have a cool protocol and now Im in search of a problem that I can apply it to. What app should I duplicate first? You need to flip this around and ask: what kind of service can I build that would deliver new or additional value to users, that is a significant enough improvement that users will switch en mass. Then go do that, get a bunch of users, and then release your protocol and encourage others to participate. There's nothing wrong with doing it all in parallel, but the primary problem -- getting users -- is large enough to consume all of your energy. EDIT: Or become a protocol evangelist... write your protocol, document it well, and start advocating it and explaining the advantages... maybe you can get Lemmy and other platforms to adopt it instead of ActivityPub. You can also write up patches to add support for it to various open source projects. Let them worry about building the remaining parts of solving the social problem... there's definitely room for multiple groups to work on solving this problem together.
- syntheweave 3y ago
  Well, to come up with the applications, you just have to go back to the original rationale to use computers: to automate the generation of some kind of answer to a question. The automation should be either equal to or higher quality than a manual alternative, or so much faster and cheaper that lower quality is acceptable. When we look at that in terms of service interfaces, it's an attempt to black-box some part of answer generation, to say "this other party will do that"...which means that it's orthogonal to the answer itself. The most direct way to get good answers would be to already know them, and everything else, like the question you ask of an interface, is secondary. Interfaces tend to be a point of friction to accessing answers because they have to assume in some sense that you know what you want to ask and how you want to phrase it. If you got the right answer from asking the wrong question you'd be extremely pleased but also confused. So it helps to establish concretely what kinds of questions are asked for each application, and turn those into interface specs. That's where a lot of the design challenge is - capturing the question/answer cycle succinctly, without overgeneralizing.