On Tue, Jan 4, 2022 at 6:02 PM Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
On Tue, Jan 4, 2022 at 5:13 PM Christopher Morrow <morrowc.lists@xxxxxxxxx> wrote:On Tue, Jan 4, 2022 at 3:14 PM Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:On Tue, Jan 4, 2022 at 12:49 PM Christopher Morrow <morrowc.lists@xxxxxxxxx> wrote:again, i'd say there's a lot of tilting at windmills still and not a lot of requirements list, that could be matched against both the current capabilities/misses and placement in the layer hierarchy.So what?Requirements make it easier to discuss solutions or direction.It's also easier to see which parts of those requirements do/don't work in today's world.I don't think SMTP is specific to the discussion, actually.Erm, the part I had intended to respond to was 'you don't need any new technology to do any of the above, you just need your MUA to deny all mail except that which matches a regex <bob}alce|jane|jim> etc...'
oh good. except that the fragment there is part of a rebuttal to your comment about: "you can never do this with..."
again though, as others have also said: "lets skip past the smtp+- discussion" that seems to keep getting put back into the conversation
and move along to: "What is it you are trying to do here, really, concretely?"
As for requirements analysis, sure, I have done a lot.
great! then you can point to a document? paper? presentation? git repository?
I am building an infrastructure that supports every mode of communication.
excellent. Requirements though?
Alice meets Bob, they bump phones, they have each other in their contacts catalog.Alice wants to phone Bob, she selects his contact, selects phone and a voice call is set up. Alice wants video, she selects video. Wants to send a short message, long message, 30TB of video, same interaction.Every interaction, secured by end-to-end encryption and authentication.Every interaction, subject to access control driven by the same policy source.
sounds nice. This sounds, though, like something a bunch more integrated into the lower levels
of the OS which the user is using on whatever device(s) they are interacting through. Or, it seems
as though putting a bunch of this into the OS and letting 'applications' hook through APIs to enable
this sort of functionality is a direction to look at. Maybe you've already covered that in your
analysis/requirements?
analysis/requirements?
This doesn't work if Alice has to think which contact app to fire up for a particular modality or remember that if she sends it as a mail, it might not get through because of spam filtering or go to different apps to separately authorize Bob for voice, video, mail and messaging.
I hear you here, the current world can get annoying, but... if the underlying infrastructure just does
the right thing then any application alice/bob use to interact (or applications!) could benefit from the
goal(s) you have sort of outlined.
I really do think that the partial space you've described would be awesome to have a solution to,
I don't think that individual 'applications' are a solution, though, it really does sound like infrastructure
and apis which the various applications can take advantage of, seamlessly.
Dream small and you will never do anything of consequence. SMTP and the telephone system are dying. Many, many proprietary walled gardens have been successfully created. The notion that an open system could also succeed in the same way they have succeeded is not 'tilting at windmills', it is the only job that is worth our time here.
you seem really fired up, that's great, I think my original question about: "Hey, got requirements?"
was really an attempt to get away from the particular 'better than X' and 'y is a fail because!' and some
very over-the-top language, trying to get back to:
"This is the problem(s) I see, here are the things I think we need to do to fix these problems"
instead of the other conversation.
"This is the problem(s) I see, here are the things I think we need to do to fix these problems"
instead of the other conversation.
