Re: [vwrap] Simulation consistency

[Dzonatas Sol <[e-mail]>]

This discussion is very helpful, and this is not about "the last word".

Figure-of-speech like ""It was designed" is not anywhere near any 
complete idea without assumptions. Appeals to common sense are still 
within the realm of figure-of-speech (and obviously does not meet 
accessibility needs). Concrete sense needs complete ideas and neither 
common-sense nor assumptions. Grammatic informal English allows 
assumptions, yet still does not allow incomplete ideas by subject-less 
or ill-verb usage. This all is very helpful knowledge (requirements) in 
documentation that makes sense to everybody. If someone writes totally 
crazy and "lacking" in abilities to type complete sentences, yet they 
write anywhere near formal English with complete ideas, that someone is 
not stupid. That someone might have took all day to write what they day 
compared to what it takes you to write in minutes. How do you think 
someone feels even when slightly mocked under such conditions?

There is no need to mock people (even non-chaletly) due to their 
accessibility needs, which you now appear ignorant about where you wrote 
"because this discussion is similarly unhelpful."

Agent Domain and Trust Domain are use-cases, which have been used as-is 
in past documentation and current glossary entries. If that is the end 
of your discussion then that proves there was no reason to complain 
about past usage of those instances (because "you can't change the 
past"). Those still exist despite the implementations did not happen 
(...publicly).

In contrast, documentation without implementation is not concrete. UNIX 
is the only system, yet, that still remains purely written in 
documentation without implementation. All other implementation based on 
UNIX are derivatives . UNIX proves exactly the depth of documentation 
that needs to exist before any real implementation can exist.

Further, this is the IETF list, and thus not limited to LL/OpenSim only 
politics of what exists and what doesn't.

Morgaine wrote:
> I like domains, Dzonatas.  I use them thousands of times daily in the 
> Domain Name System, and such domains have very precise definitions, 
> concrete services that implement them, a well defined network protocol 
> and many APIs and bindings.  These domains are something concrete, and 
> productive.
>
> In contrast, Agent Domain and Trust Domain are neither.
>
> I'll leave it at that and let you have the last word, because this 
> discussion is similarly unhelpful.
>
>
> Morgaine.
>
>
>
> ========================
>
> On Sun, Apr 3, 2011 at 10:10 PM, Dzonatas Sol <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     You mock fluffy clouds, yet you wrote "It was designed". To not
>     write even close to formal English, when you made use of
>     subject-less sentences, and complained about meanings and
>     (glossary) usage, is incongruous.
>
>     Just state you don't like the word "domain". There is no need to
>     mock me or anybody else to win points.
>
>     Morgaine wrote:
>
>         Very good points made by Meadhbh, and I agree 100%.
>
>         It's an unfortunate reality that a puzzlingly large proportion
>         of users have a hard time grasping the total absence of
>         content security in a platform architecture which sends nearly
>         all content types to client machines by design.� It was
>         designed that way for very good reasons, and those reasons are
>         as valid today as they were at the time that it was being
>         designed, but it can be hard to get across that this is how it
>         is intended to be and not a fault.� Some people's aspirations
>         are destined to be forever unsatisfied because this does not
>         reflect their concept of digital reality.
>
>         It doesn't matter how much machinery of trust or security or
>         encryption or DRM or VPN or anything else we employ, at the
>         end of the day the client endpoint has open data at its
>         disposal which it needs to get its job done, and no technical
>         barriers against doing with it whatever else it wishes.
>
>         It's incongruous that we speak of "trust domains" (it's those
>         fluffy clouds again) when all we really have are
>         cryptographically assured endpoint identification and no trust
>         at all.� You can't trust someone whom you don't know as a
>         person, and it's a fiction to claim that trust has been
>         obtained.� We would be more honest if we exchanged "Trust
>         Placebo Tokens", and then we could at least laugh at our own
>         eclectic joke, while openly admitting that we are not actually
>         providing anything of value beyond knowledge of the endpoint.
>
>         As you say, there is nothing we can actually do about this,
>         because all we can do is exchange messages containing
>         structured information, and we can't control people.� "Trust"
>         about what happens beyond the endpoint is something that our
>         technology cannot convey, and really using terms that suggest
>         otherwise just deludes people who don't have the background to
>         know better.
>
>         We should avoid doing that, even when a phrase sounds too sexy
>         to give up.
>
>
>         Morgaine.
>
>
>
>
>
>         =========================
>
>         On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick
>         <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>
>            there is no way for a protocol to enforce the processing
>         behavior on
>            either end of a connection unless you want to mandate the
>         use of MAC
>            or DRM.
>
>            the reason you "trust" someone is that you can't complete a
>            transaction without trusting them. in the original VWRAP
>         model, we
>            assumed assets were bits of data and meta-data that could
>         be securely
>            moved around. "license" was just another bit of meta-data,
>         as was
>            "distribution." the protocol didn't require you to add
>         either of these
>            fields. neither did the protocol require you to honor them.
>
>            that's because there's no way a protocol can REQUIRE a
>         consumer of
>            information do anything with that info.
>
>            instead, we provided a mechanism to communicate structured
>         information
>            and described the processing expectations. but ultimately,
>         if a "bad
>            actor" that wants to steal digital content participates in
>         a protocol
>            transaction, it won't matter that the protocol will say "honor
>            permissions metadata." there is nothing magical about
>         protocols that
>            require adherence to specified processing expectations.
>
>            -cheers
>            -meadhbh
>
>
>            --
>            meadhbh hamrick * it's pronounced "maeve"
>            @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>         <mailto:[e-mail]>
>            <mailto:[e-mail] <mailto:[e-mail]>>
>
>
>
>
>            On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood
>         <[e-mail] <mailto:[e-mail]>
>            <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>            > On Sat, 2 Apr 2011 10:01:43 -0700
>            > Meadhbh Hamrick <[e-mail]
>         <mailto:[e-mail]>
>            <mailto:[e-mail] <mailto:[e-mail]>>>
>         wrote:
>            >
>            > This is not exactly what I was refering too :p
>            > What I meant is that it should be possible to tag
>            > a creation as "GPL-ed" or "Common Creations" etc,
>            > and that the result is that that thing stays that
>            > way. That it is not possible to accidently break
>            > such free licenses by making it 'no mod' because
>            > someone forgot to check a box.
>            >
>            > Although this seems to be a client-side issue,
>            > and thus something internally to grid (and thus
>            > not related to VWRAP), it DOES mean that such
>            > information has to be supported at all levels:
>            > the fact that something IS explicitely allowed
>            > to be copied etc, has to be stored in asset
>            > servers and be transported to others who obtain
>            > a copy if it.
>            >
>            > If everyone is willing to work as hard on guaranteeing
>            > support for such free product as on the use case
>            > for proprietary products, then I'm willing to think
>            > hard of ways to support the latter.
>            >
>            >> yes. there is something missing in the protocol. it's trust.
>            you don't
>            >> put "trust" in a protocol, you put "security" in a
>         protocol. at the
>            >> end of the day, the people using this protocol will need
>         to decide
>            >> whom they trust. this is why there was a security model
>         and the
>            >> ability of the protocol to "securely carry trust."
>            >>
>            >> the idea is that the protocol would carry cryptographically
>            >> unforgeable attestations of an endpoint's identity. this
>         identity
>            >> would then be evaluated by protocol participants to see
>         if it is
>            >> "trusted."
>            >>
>            >> there's no place in the protocol that says "you must trust a
>            specific
>            >> entity," but rather a mechanism deployers can use to
>         carry the
>            >> identity of people wishing to be trusted.
>            >>
>            >> at the end of the day, an asset service should only barf up
>            assets to
>            >> trusted simulation services. simulators SHOULD only
>         allow people on
>            >> the grid they trust (for some definition of the word
>         "trust.")
>            >>
>            >> if you're a company like Linden that needs to respond to
>         DMCA
>            takedown
>            >> requests, you're likely to require the client trust knob
>         turned
>            up a
>            >> bit. if you're an enterprise, you're going to want that
>         trust knob
>            >> turned all the way up. if you're the pirate bay, you're
>         going to
>            >> intentionally want that trust knob turned all the way down.
>            >>
>            >> as protocol developers, it's our duty to create a
>         protocol that
>            meets
>            >> everyone's use cases. so... i mean... feel free to try
>         to define a
>            >> protocol that mandates the use of DRM or blesses a
>         particular trust
>            >> point, but the likelihood of it being widely supported is..
>            >> approximately nil.
>            >>
>            >> my recommendation has always been... "define mechanism, not
>            policy."
>            >>
>            >> -cheers
>            >> -meadhbh
>            >> --
>            >> meadhbh hamrick * it's pronounced "maeve"
>            >> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>         <mailto:[e-mail]>
>            <mailto:[e-mail] <mailto:[e-mail]>>
>
>            >>
>            >>
>            >>
>            >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood
>         <[e-mail] <mailto:[e-mail]>
>            <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>            >> > On Sat, 2 Apr 2011 14:12:59 GMT
>            >> > "[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>"
>
>            <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>         wrote:
>            >> >
>            >> >> BTW, the Red Zone statistics of 9 million �scans with
>         only
>            78,000
>            >> >> rogue viewers captured lets us know that this �problem is
>            >> >> exaggerated -- and usually by engineers who claim
>         there is no
>            >> >> �technical solution.
>            >> >
>            >> > Just for the record, from a hacker/engineer: there is no
>            technical
>            >> > solution. It is possible to copy everything (and
>         without being
>            >> > detected by a "Red Zone" which can only detect rogue
>         viewers that
>            >> > were released to the public and explicitly make a
>         point of being
>            >> > detectable in the first place (call that bragging: no
>         fun in
>            >> > releasing a "k3wl" viewer if others (or even the coder
>         himself)
>            >> > can't see that it is being used.) So, there is a
>         psychological
>            >> > advantage for the detectors, but not really a
>         technical one.
>            >> >
>            >> > Lets concentrate on textures for the moment to explain
>         this.
>            >> >
>            >> > In order to see an object, or clothing, with the
>         appropriate
>            >> > textures, those textures have to be downloadable for
>         the viewer.
>            >> > There is nothing you can do about that short of
>         running the whole
>            >> > viewer server-side and providing a video. But even in that
>            case it
>            >> > would technically be possible to rip the textures:
>         they are still
>            >> > visible (ie, you could make a screenshot of the
>         surface of a
>            wall).
>            >> > I don't consider the video-broadcast to even be remotely
>            >> > interesting, certainly not from the viewpoint of VWRAP
>         so lets
>            >> > forget that for the moment and just accept that it is
>            possible for
>            >> > anyone to store whatever they SEE to their harddisk.
>            >> >
>            >> > Secondly, if the first creator could upload this
>         texture then
>            so can
>            >> > the ripper. And don't tell me software exists that can
>         detect if
>            >> > an uploaded texture "looks like" one of the already
>         existing
>            billion
>            >> > textures that were uploaded before. If the texture is
>         converted
>            >> > twice, ie from jpeg2000 to jpg to tga and then
>         uploaded, then
>            you'd
>            >> > need a human to look at the original and the newly
>         uploaded
>            texture
>            >> > at the same time to judge that it is MAYBE a copy - which
>            then can
>            >> > only be proved in court if the original creator can prove
>            that his
>            >> > original textures are 100% his own and not, for example,
>            downloaded
>            >> > from the internet somewhere (because in that case the
>         other
>            >> > uploader could have used the same source).
>            >> >
>            >> > A real problem, currently in SL, is imho the complete
>         lack of
>            >> > support for FREE things. The amount of restriction (for
>            people with
>            >> > honest viewers) is tremendous: if you're not an expert
>         or do
>            not pay
>            >> > attention for a second, then your creation is not
>         truely free
>            >> > anymore. Everything defaults to very copyleft unfriendly
>            settings.
>            >> > I'm trying to get my friends, who are very willing in that
>            regard,
>            >> > to only create full permission stuff, but it's simply near
>            >> > impossible to keep something full permission and often
>         we're
>            stuck
>            >> > with something nobody else can change or edit because
>         the creator
>            >> > forgot to set the bit of the contents of an object
>         after changing
>            >> > the group etc blah blah...
>            >> >
>            >> > For example, last a good friend of me wanted my help with
>            making a
>            >> > large amount of changes on his sim: hunderds of
>         objects had to be
>            >> > adjusted... He was willing to:
>            >> > 1) Add me to any group necessary.
>            >> > 2) Give me his build rights
>            >> > 3) Transfer any object to me (temporary ownership
>         transfer)
>            >> > 4) Make any adjustments to the objects and the objects
>         contents
>            >> > � needed to allow me to access what I needed to access.
>            >> > etc etc
>            >> >
>            >> > The end result: He had to do it all by himself. It was
>            impossible to
>            >> > give me enough access to help him (for those who don't
>            believe that,
>            >> > one of things involved changing the "anyone can move"
>         bit of an
>            >> > object in the contents of objects: it is not possible
>         to take
>            >> > anything out of the contents (ie copy it to your
>         inventory) when
>            >> > it's no transfer, and therefore you can't edit it, even
>            though it's
>            >> > modify and you get all the rights that the owner can
>         give you).
>            >> >
>            >> > Sorry, but that is unacceptable; and it CLEARLY shows that
>            >> > something is missing from the protocol.
>            >> >
>            >> > Now the above example doesn't show that a free object
>         is not
>            >> > supported, it only make clear that non-free objects
>         can be very
>            >> > annoying even in situations where the owner has all
>         the rights to
>            >> > do what he wants to do. There are many other such
>         examples.
>            Hence,
>            >> > it shows that it is very annoying that an object is
>         non-free by
>            >> > default at so many levels that you need an IQ of over
>         140 to
>            create
>            >> > one and those permissions erode quickly to non-free.
>         Even the so
>            >> > called "freebies" are non-free by the way: they are
>         almost always
>            >> > no transfer. Hell, even the default shape that you can
>         when you
>            >> > create a new account is no transfer, what kind of
>         insanity is
>            that?!
>            >> >
>            >> > I think you might find a lot of people, like myself, a
>         lot more
>            >> > willing to help out with thinking of ways on how to
>         protect
>            >> > property in virtual worlds when first it is assured that
>            those who
>            >> > want to create things that are FREE are equally
>         supported as the
>            >> > commercial guys out there.
>            >> >
>            >> > --
>            >> > Carlo Wood <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>            >> > _______________________________________________
>            >> > vwrap mailing list
>            >> > [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>
>            >> > https://www.ietf.org/mailman/listinfo/vwrap
>            >> >
>            >
>            >
>            >
>            > --
>            > Carlo Wood <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>            > _______________________________________________
>            > vwrap mailing list
>            > [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>
>            > https://www.ietf.org/mailman/listinfo/vwrap
>            >
>            _______________________________________________
>            vwrap mailing list
>            [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>
>            https://www.ietf.org/mailman/listinfo/vwrap
>
>
>         ------------------------------------------------------------------------
>
>         _______________________________________________
>         vwrap mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/vwrap
>          
>
>
>
>     -- 
>     --- https://twitter.com/Dzonatas_Sol ---
>     Web Development, Software Engineering, Virtual Reality, Consultant
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>   


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant